Reject writes based on a stale read

Give every mutable resource a version tag, and refuse a write whose tag no longer matches, so an agent acting on an old read cannot silently overwrite a change it never saw.

Why

Agents read, reason and then write, and the reasoning can take seconds or minutes. In that window a person, a webhook handler or a second agent can change the same record. If the server applies whichever write arrives last, the earlier change disappears and nobody is told. HTTP calls this the lost update problem. RFC 9110 says If-Match is most often used with state-changing methods to prevent accidental overwrites when several clients act in parallel on the same resource: the server sends an ETag with the resource, the client returns it in If-Match, and a mismatch gets 412 Precondition Failed, a status that exists so a method is not applied when the resource is in an unexpected state. Google's API design guidance (AIP-154) states the same rule for any API: two processes updating one resource in parallel can "stomp over" each other's work, an etag lets the server confirm the client's copy is current, and a mismatched etag must be rejected with ABORTED. For an agent, that rejection is useful information: re-read, check the decision against the new state, then try again. Idempotency (AX-SYS-15) makes the same request safe to repeat; a conditional write stops a different request built on outdated data.

Do

Return an ETag on every read of a mutable resource, require If-Match on state-changing writes, and answer a mismatch with 412 and the current version.

Don't

Apply whichever write arrives last, or report a version conflict as a generic error the agent cannot act on.

Artifact

GET /v1/refund_cases/rc_88
-> 200 OK
ETag: "v7"

PATCH /v1/refund_cases/rc_88
If-Match: "v7"
{ "status": "approved", "amount": 4900 }

-> 412 Precondition Failed
ETag: "v8"
Content-Type: application/problem+json
{ "title": "Case changed since you read it", "current_etag": "v8", "changed_by": "human:jane", "re_read": "/v1/refund_cases/rc_88" }

The agent re-reads version v8, sees that a person already approved a partial refund, and decides again from there.