Validate before claiming
An agent's claim-and-resolve validates the payload first, so a rejected answer never leaves a row locked to the agent.
The situation
An agent picks up review rows and answers them. If it claims first and its payload then fails validation, the row sits locked to the agent until the window lapses and people cannot touch it.
The recipe
{ "escalation_id": "esc-a1b2" }{ "escalation_id": "esc-a1b2", "resolver_id": "review-agent", "payload": { "approved": true, "notes": "Matches the purchase order" }}check_resolution returns the row’s form schema (fields, types, x-lt-bind paths) and reports schema_enforced: true when the role enforces. claim_and_resolve validates the payload against that schema before it claims.
The guarantee
A rejected payload returns the canonical 422 body with isError: true and leaves the row unclaimed. resolve-by-metadata holds the same line inside its atomic statement: an enforcing target answers validation_required with nothing written, and the validated payload re-runs with the row id asserted and pending re-checked. See Schema enforcement.
Related patterns
Resolving from anywhere
One contract, one 422
Every resolve surface rejects a bad payload with the same 422 body naming each field, so every client handles validation one way.
Resolving from anywhere
Roll out enforcement by watching 422s
Turn on schema enforcement for one role and let each 422 name the submitter and the exact fields it is missing.
Agents and MCP
Humans as tools
An agent routes work to a person through the same tool protocol it uses for everything else, and gets the typed answer back.
Resolving from anywhere
A claim is a work lock
A claim names a holder and a window. While the window is live nobody else can resolve the row, and when it lapses the row is back in the pool.