Concept
Where Ablo fits in a multi-agent system
Ablo Team7 min read
Claims: the unit of human–agent coordination
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.
Filed under Concept
By Ablo Team
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.
The collaboration layer for humans and agents
Let people, server actions, and AI agents work on the same data without overwriting each other — on top of the Postgres you already have.