More writers does not mean more throughput
Say you give twenty autonomous agents write access to the same shared state. The bottleneck does not move to the model. It moves to whoever has to reconcile the collisions.
Get the field notesContents
The instinct when a shared system gets busy is to add more workers: more agents drafting, more agents fixing, more agents shipping. It works right up until those agents share one piece of state they all want to write to at the same time: a single branch, a single record, a single queue. Past that point, adding writers does not raise throughput. It raises the collision rate.
#Why this looks like a spike instead of a trend
A shared-state bottleneck rarely shows up as a steady slowdown. It shows up as a run of retries that briefly look self-correcting, then a spike: several writers submit in the same short window, each successful write moves the target, and every writer still queued behind it now has to redo its check against a target that has already moved again. The backlog does not grow by one at a time. It compounds.
That shape fools a quick check. A single glance mid-spike sees "behind by a few, retrying, seems fine." Only tracking the number over the whole window shows it climbing rather than holding steady, which is the actual signal that retries alone are not closing the gap.
#Retries are not a substitute for a queue
The reflexive fix, when a write gets refused because the target moved, is to retry against the new target. That works for the first collision. It does not work as a strategy, because retrying doesn't reduce how many writers are still racing for the same slot; it just decides which one of them gets refused next.
The actual fix is ordering, not persistence:
- One writer at a time per shared target. Everyone else queues instead of racing and retrying.
- A visible queue depth. Not just a pass or fail signal per attempt, so a growing backlog is a metric someone watches instead of a surprise someone discovers.
- A named owner for reconciliation. When the backlog does grow, someone's job is explicitly to clear it, not whoever happens to be nearby when the alert fires.
The agents themselves do not need to change. The shared target does: it has to enforce one writer at a time, even while everything pointed at it keeps running fully in parallel.
#The audit this deserves
- Name every piece of shared state your agents write to concurrently: a branch, a database row, a queue, a document.
- For each one, ask whether writers queue for it or race for it. Racing plus retry is not a queue.
- Check whether backlog depth against that target is a number someone can see, or only inferable from a string of individual failure alerts.
- If nobody owns reconciling a backlog when it grows, that is the gap, not the collision count itself.
More writers were never going to be the constraint on their own. What was missing was a place for them to wait their turn.
See how EP treats operational coordination as part of the build, not an afterthought.
Get the field notes.
One useful note on AI operations, no hype. A weekly roundup, and we skip any week without something worth sending.
Double opt-in. Unsubscribe any time. Read our privacy notice.
Keep reading
- · 4 min
Multi-agent systems fail at the seams, not the model
The largest study of multi-agent failures found the model almost never causes them. The leverage is cheap plumbing at the seams.
- · 3 min
The check that cannot fail is not a check
A safety gate that has never been triggered looks identical to one that is broken. The difference only shows up when you go looking for the trigger it should have caught.
- · 6 min
What business process automation actually costs
Almost nobody publishes a price for automation work, and the reason is not evasion. Here is the cost structure underneath a quote, and how to read one.