The Human Coordination Ceiling

Nothing dramatic happens when a manually supervised agent fleet reaches capacity. The agents keep running, tests finish and pull requests still appear.

They just spend longer waiting for somebody to decide what happens next.

At that point, adding another worker does not increase delivery. It increases the inventory of unfinished decisions. The bottleneck has moved from producing code to coordinating, evaluating and recovering work, while the human in the middle remains stubbornly singular.

This is the human coordination ceiling. It is not a magic number of agents. It is the point at which useful results arrive faster than we can turn them into accepted, integrated and recoverable changes.

Output Is Not Finished Work

The previous part of this series covered the mechanics of moving from scripts to orchestration systems. Those systems can make ownership, routing and state more explicit. They do not remove the decisions which need judgement.

An agent finishing a task creates an input to another process:

agent result
    -> inspect evidence
    -> resolve open decisions
    -> reconcile with other changes
    -> verify the combined system
    -> accept, reject or recover

Every arrow can become a queue. A test failure needs diagnosis. A clean patch can embody the wrong architectural choice. Two correct local changes can disagree at their boundary. An apparently finished task can reveal that the original specification was impossible.

Counting running agents, tool calls or generated patches ignores all of that. The useful unit is a result which has survived the route into the system. Until then, it is work in progress, regardless of how confidently the agent announced completion.

When arrivals briefly exceed our capacity to close them, the queue grows. As the queue ages, its items become more expensive. The base branch moves, the task context fades, assumptions change and the person reviewing it has to reconstruct why the work existed in the first place.

This is why the ceiling can arrive with three agents in one repository and remain distant with many more in another. It depends on the coupling of the work, the strength of the evidence, the cost of a wrong decision and the amount of human judgement each result still requires. A universal fleet limit would be reassuring. It would also be fiction.

Attention Splinters Before Time Runs Out

A human coordinator does more than spend minutes on each task. They maintain a changing model of the whole operation: which assumptions are current, which interfaces are stable, what is blocked, which failures are related and where an exception would be dangerous.

Switching from a database migration to a browser failure and then to a security review is not merely opening three tabs. Each result has a local history which must be loaded before its evidence means anything. The agent that produced it had that context while working; the reviewer often receives a summary, a diff and a collection of logs after the fact.

Summaries and raw transcripts trade compression against the effort of finding the important parts; neither makes that choice for the reviewer. A dashboard can expose state, but it cannot decide which state matters. The coordination burden is partly time and partly the cost of rebuilding a trustworthy mental model for every decision.

Interruptions make this worse. When every worker can ask a question at any moment, the fleet turns the operator into an interrupt handler. Urgent and merely recent work compete for the same attention. A quick answer given without reloading the relevant constraints may unblock several agents in the wrong direction.

The obvious response is to ask agents to continue whenever the human is unavailable. That is safe only when the decision has already been bounded. Retrying a flaky network request within a budget can be policy. Choosing whether a migration may lose data is not a sensible default for an unattended loop.

Review, Integration and Recovery Share One Budget

It is tempting to treat review as the only human bottleneck. It is usually three related queues.

The review queue contains claims waiting to be judged. Deterministic checks can reject known failures, but somebody still has to decide whether the evidence matches the intended outcome and whether the remaining risk is acceptable.

The integration queue contains individually plausible changes waiting to meet. Time in this queue creates staleness. A branch which was clean yesterday may now need conflict resolution, a new migration order or another pass through CI. Increasing generation without increasing integration capacity produces more rebasing, not more product.

The recovery queue contains work whose happy path ended. An agent lost its context, a tool timed out after an external effect, a supposedly isolated test modified shared state, or the integrated system failed outside the worker’s test boundary. Recovery needs provenance and judgement: what ran, what changed, what can be retried and what must be reversed?

These queues draw from the same people. An hour spent reconstructing an ambiguous failed run is an hour not spent reviewing the next successful one. Worse, recovery arrives unpredictably, so planning the fleet against average review time creates a system with no room for exceptions.

That spare capacity can look inefficient on a dashboard. It is the capacity which stops one bad run from paralysing everything behind it.

A Large Experiment Shows the Boundary

Cursor’s research into long-running multi-agent development is useful here because the team documented several designs which failed before its final one.

The eventual system moved routine planning, delegation, hand-offs and reconciliation into a recursive planner-worker structure. It also logged agent messages, actions and command output with timestamps so runs could be inspected and replayed. Cursor deliberately accepted some temporary errors and proposed a final green branch with a fix-up pass before release. That release pass was a design inference in the report, not a demonstrated gate.

This does not establish how many agents one developer should run. Cursor describes a research browser, a dedicated harness, permissive intermediate states and substantial compute. The relevant lesson is that the human ceiling was crossed by changing the control system, not by teaching one person to watch more terminals.

Removing a human from each transition does not remove coordination. It turns coordination decisions into policy, software and observable state. That can scale further, but mistakes in those rules also scale further.

Move Rules Out of Human Memory

The first response to a coordination ceiling should not be a grand platform. It should be to identify which repeated decisions are already mechanical enough to encode.

Useful candidates include:

• admitting work only when its dependencies, owner and completion condition are known;
• attaching provenance and verification results to the result automatically;
• routing a failure to the owner of the affected boundary;
• preventing a task from advancing when a required check fails;
• checkpointing state so a stopped run can resume without guessing;
• applying time, cost and retry budgets before a loop begins;
• limiting work in progress when review or integration starts to age.

These mechanisms reduce coordination load because they prevent avoidable questions and preserve the answer to questions already settled. They do not decide product direction, invent missing business rules or accept consequential risk on our behalf.

Adding an agent as a supervisor can help, but only if its authority and evidence are explicit. Otherwise we have moved the queue behind a fluent intermediary. The supervisor can summarise five branches and still share their false assumption. It can declare integration complete while looking at five local test reports rather than the combined revision.

The same caution applies to a command centre full of status lights. Visibility is valuable, especially during recovery. Yet a red light without an owner, a recovery action or a stop rule is simply a brighter interruption.

Measure Waiting, Not Busyness

The ceiling becomes visible in flow metrics long before it becomes obvious in a model bill. I would watch:

• how long completed work waits for an accept, reject or revise decision;
• how many changes are simultaneously running, waiting for review, integrating or recovering;
• how often results need to be redone because their base or assumptions became stale;
• how many human interventions are required per accepted change;
• how much agent and CI cost is spent on work which is discarded;
• how long it takes to restore a known state after a failed run.

None of these produces a universal target. A security-sensitive migration should wait for the right reviewer. Three competing research branches may be discarded by design. The point is to reveal where work accumulates and whether adding concurrency improves accepted delivery or merely moves cost into a quieter queue.

Ageing completed work is a reason to reduce the work-in-progress limit. Repeated operational questions belong in the workflow, while a fresh architectural decision for every result suggests that the specification or decomposition is not ready for more parallelism. Failures which cannot be reconstructed point to state and observability work before further autonomy.

This may leave agents idle. That is cheaper than keeping them busy producing decisions nobody can responsibly make.

The Ceiling Is a Design Signal

Better task boundaries, tests and orchestration can raise the human coordination ceiling. They cannot make attention infinite. Eventually, a manually operated fleet becomes a production system whose queues, policies, evidence and failure recovery need engineering in their own right.

Crossing that boundary too early creates platform work for a problem we do not have. Crossing it too late leaves one person performing scheduling, integration and incident response through a collection of terminal windows.

The signal is not the number of agents. It is repeated, measurable waiting around human decisions which could already be represented safely in the system.

At that point, we are no longer improving the workers. We are ready to build the software factory.