Execution controls

Concurrency Control for Agents

What if two agents change the same record at once?

Reference notes by Min · Reviewed October 15, 2026

Working governance definitionAlso: Lost updates · Optimistic concurrency · Conditional writes2 primary references

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.

  1. Submit the agent’s proposed edit with the version it reviewed.
  2. Reject the stale update at the service.
  3. Show the new state and obtain any required fresh approval.
Illustrative scenario, not a reported deployment.

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?

References

Primary documents reviewed for this entry. Examples and implementation patterns are editorial synthesis.

  1. IETF RFC 9110: HTTP Semantics, conditional requests ↗Accessed October 15, 2026
  2. MITRE CWE-367: Time-of-check Time-of-use Race Condition ↗Accessed October 15, 2026