The record changed while your agent was thinking

An agent reads a customer’s delivery address and starts preparing an order. While it works, a person changes that address. Thirty seconds later, the agent saves its carefully prepared shipment using the old destination. Its reasoning may be sound. Its information is no longer current.

Adding a message telling agents to check for updates can reduce this problem. It cannot close the interval between the last check and the write. That interval belongs to the application’s concurrency rules.

A read is an observation, not a reservation

Reading a record tells a participant what was available at that point. It does not promise that other participants will leave it alone. This is easy to overlook when a model receives a neat snapshot as context: the snapshot looks complete, while the application continues changing outside it.

The ICML position paper by Yang and colleagues frames failures of this kind as concurrency anomalies. Its contribution is a design argument, not a new benchmark victory: shared mutable state and long inference windows make isolation and validation explicit infrastructure concerns. The paper discusses the competing costs of blocking and retrying; it does not establish one universally best protocol.

Check the premise, not only the destination

Suppose the agent creates a shipment row from a customer row. Checking whether the new shipment already exists will not reveal that the customer’s address changed. The dependency lives on the row that was read. A useful guard records that dependency and validates it when the proposed shipment is applied.

This makes a rejection actionable. The agent needs to know which premise changed, retrieve the new value, and reconsider the result. Repeating the same write with the same old address would simply reproduce the error. Conflict handling is part of the workflow, including a bounded retry or a person’s review when the business decision has changed.

Decide when waiting is cheaper

For a quick calculation on a rarely contested record, letting participants proceed and validating their updates can keep work moving. For a costly model call on a popular resource, repeated rejection can waste more work than taking turns. A reservation also needs an expiry and a clear response when ownership is lost.

Ablo exposes this choice through explicit captured reads and claims. A write with named read dependencies rejects stale context; a row claim coordinates access to its selected target across a slow gap. These mechanisms protect operations routed through the integration. Incidental reads, arbitrary filesystem writes, and unrelated external services do not acquire protection automatically.

Test the gap deliberately

A useful acceptance check pauses one participant after its read, changes a dependency from another participant, then resumes the first. Check both a same-row update and a change derived from a different row. The expected outcome should be explicit: reject, recompute, or request review. A finished agent turn alone says nothing about whether that boundary held.