Concurrency Control for Agents
What if two agents change the same record at once?
Reference notes by Min · Reviewed October 15, 2026
Definition
Concurrency control coordinates overlapping operations on shared state. In agent workflows, it prevents a proposal based on an old record from silently overwriting a more recent change and establishes how conflicts are resolved.
Agents often take time to reason between reading a record and writing it. During that interval, another user or workflow can make a legitimate change. The agent’s proposal may remain internally consistent while no longer fitting the current resource state.
What it covers
- Version
- The state the agent actually read.
- Condition
- The state required for a write to succeed.
- Atomicity
- Checking and updating without an intervening change.
- Conflict
- Re-reading, reviewing or escalating competing edits.
Identify the unit that needs protection. A single record version may be enough for one update, but a transfer across accounts may require a stronger transaction boundary. Document what the chosen mechanism protects and what remains outside its guarantee.
In practice
Practical design patterns by Min.
- Include a resource version with consequential proposals.
- Use server-enforced conditional writes where available.
- Reassess changed state before retrying a rejected update.
Keep conflict responses distinct from temporary outages. A conflict is new information about the resource, not simply a reason to repeat the request. Recompute or request review using the updated state and preserve the original proposal for investigation when relevant.
Research notes
Source-grounded details and editorial applications. Follow each link for the original document.
Conditional requests can prevent stale updates
RFC 9110 defines conditional request fields including If-Match. Correctly implemented server-side preconditions can prevent an update when the resource no longer matches the expected representation.
Source: IETF RFC 9110: HTTP Semantics, conditional requests ↗
Working example
Two assistants edit a delivery address
One agent reads an order while a human changes its destination.
- Submit the agent’s proposed edit with the version it reviewed.
- Reject the stale update at the service.
- Show the new state and obtain any required fresh approval.
Why the controls matter
The delivery example should preserve the human’s newer edit until a valid decision resolves the conflict. A generic retry wrapper can defeat this intention if it automatically fetches a fresh version while retaining an outdated proposal.
Common pitfalls
- Checking versions only in the interface.
- Retrying the same stale write until it succeeds.
- Assuming sequential chat messages imply sequential service execution.
Locks and leases also have failure modes, including expiry and abandoned work. Prefer mechanisms supported by the authoritative service and test overlapping requests. A local lock inside one agent process cannot coordinate other independent writers.
Questions for operational review
Use these questions to decide what evidence your team needs. They are editorial prompts, not a compliance checklist.
- Which version did the reviewer see?
- Is the condition checked atomically with the update?
- What does the workflow do when a conflict is reported?
Articles linking here
References
Primary documents reviewed for this entry. Examples and implementation patterns are editorial synthesis.
- IETF RFC 9110: HTTP Semantics, conditional requests ↗Accessed October 15, 2026
- MITRE CWE-367: Time-of-check Time-of-use Race Condition ↗Accessed October 15, 2026