·3 min read·multi-agent · ai-operations · loop-engineering

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 notes
Contents

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

  1. Name every piece of shared state your agents write to concurrently: a branch, a database row, a queue, a document.
  2. For each one, ask whether writers queue for it or race for it. Racing plus retry is not a queue.
  3. Check whether backlog depth against that target is a number someone can see, or only inferable from a string of individual failure alerts.
  4. 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.