# Claims: the unit of human–agent coordination An agent reads, thinks, calls an LLM, then writes — and the row can move underneath it. A claim is a short FIFO lease an actor takes before slow work, so people and agents never clobber each other. _Concept · 2026-06-18 · 5 min read · by Ablo Team_ An agent’s write is rarely instant — it reads, thinks, calls a model or a tool, then writes back. A claim is the short lease it takes first, so the row it’s working on can’t be overwritten out from under it. ## Key takeaways - An agent’s work spans a read → think → write gap; without coordination, a concurrent edit is silently lost. - A claim is a FIFO lease on a row taken before slow work starts; contention makes the next claimant wait and re-read the fresh row. - Claims treat a person editing in the UI and an agent calling the API as the same kind of actor competing for the same row. - Releasing a claim is automatic with `await using`, so a crashed or abandoned agent can’t hold a row hostage. The hardest part of letting AI agents write to your application data is not the write itself — it is the gap before it. An agent reads a row, reasons about it, calls an LLM or an external tool, and only then writes back. That gap can be seconds long, and in those seconds a teammate or another agent can change the same row. Whoever writes last wins, and the other change vanishes. A claim closes that gap. ## The read–think–write gap Optimistic concurrency works when writes are quick: read a value, write it back, and if the version moved, retry. Agent work breaks that assumption because the “think” step is slow and expensive — you do not want to throw away a 10-second LLM call and redo it just because a label changed. The claim flips the model: instead of detecting a conflict after the fact, the actor announces its intent to work on a row before it starts. ## A lease, not a lock A claim is a lease, not a permanent lock. It is FIFO: if someone already holds the row, your claim waits its turn, and when it is granted you are handed the current, fresh row — never a stale snapshot. Leases expire and release automatically, so an agent that crashes mid-record does not strand the row. The result is that slow, multi-step agent work and fast human edits can target the same data safely, in order, without a separate “agent mutation path.” ## People and agents, one rulebook Crucially, a claim does not care whether the actor is a person dragging a slider in the UI or an agent calling the API. They compete for the same row under the same FIFO rule. That symmetry is what makes a shared human-and-agent workspace possible: the coordination primitive is identical for both. ## Frequently asked questions ### How is a claim different from a database lock? A claim is an application-level FIFO lease scoped to a row and an actor, with automatic expiry and release. Unlike a long-held database transaction lock, it is designed to be held across slow work (an LLM or tool call) without pinning a database connection, and it queues fairly so waiting actors get the fresh row when their turn comes. ### What happens if an agent holding a claim crashes? Claims release automatically — with `await using` the lease is dropped when the scope exits, and leases also expire — so a crashed or abandoned agent cannot hold a row hostage. The next actor in the FIFO queue is granted the row. --- Canonical URL: https://www.abloatai.com/blog/claims-the-unit-of-coordination Also machine-readable on this domain: /llms.txt, /llms-full.txt, /openapi.json, /sitemap.xml, /robots.txt