One agent returns a patch. You review it, ask for a correction and continue.
Five agents return five patches in the same hour. They have made different assumptions, two changed the same interface, one discovered that the specification was wrong, and all five are waiting for a decision. The models may be faster. You are not.
This is why moving from one agent to many is not the next setting on a productivity slider. It changes the shape of the work. Generation becomes parallel, while much of the coordination, judgement and accountability remains stubbornly serial.
In the previous part of this series, I argued that the harness around an agent determines how safely it can work. That remains true. With several agents, though, we also need to decide which work may happen at the same time, how partial results meet again and how much unfinished work a human can absorb.
More workers, a different system
With one agent, the feedback loop is easy to see:
- describe the task;
- let the agent work;
- inspect its evidence;
- accept, correct or discard the result.
Add a second agent and there are now two loops plus a third concern: their interaction. They may rely on the same API, edit the same configuration, compete for the same test environment or make incompatible architectural choices without touching a common file.
File isolation helps with one of those problems. It does not solve the others.
The important object is no longer a prompt. It is a graph of work. Some tasks are independent, some require an earlier decision, and some only look independent until implementation reveals a shared dependency. Starting every node at once does not remove those edges; it merely discovers them through merge conflicts and rework.
This is a coordination discontinuity. The operator has to maintain ownership, dependencies, current state and completion criteria across several concurrent streams. A good result from each stream is not sufficient if the combined result is incoherent.
The economics are not linear either
The attractive arithmetic is obvious: if one agent produces one unit of work, five agents should produce five. Unfortunately, the invoice follows that multiplication more reliably than the useful output does.
For example, Anthropic’s documentation for parallel Claude Code sessions says that running ten agents consumes subscription quota roughly ten times as fast as running one. That is product-specific behaviour, not a law for every agent system, but the broader cost categories remain:
- every agent consumes model tokens and compute;
- every task needs enough context to start correctly;
- duplicated exploration costs money even when only one answer survives;
- integration and review consume human time;
- a wrong shared assumption can invalidate several branches at once.
The useful numerator is accepted work, not generated code. A fleet that produces eight patches of which two are understood, integrated and shipped may be worse than one agent producing a single clean change. It has created more inventory and more decisions, not necessarily more value.
There is also a latency trade-off. Parallel work can reduce elapsed time when tasks are genuinely independent. It can increase total effort at the same time, because repeated setup, overlapping investigation and reconciliation are the price paid for that lower latency. Sometimes that is a very good bargain. An urgent incident investigation may justify three independent hypotheses even though two will be discarded. A routine dependency update probably does not.
I would therefore budget parallel agents as we budget any other expensive concurrency: against a deadline, a cost ceiling and the probability that the branches produce independently useful information.
Review becomes the scarce resource
Generated work arrives faster than judgement can be delegated. That moves the bottleneck.
Tests and static checks can reject known classes of bad output. They are the backpressure that stops obviously broken work travelling further. They cannot decide whether two individually valid designs belong in the same system, whether a migration is operationally acceptable, or whether the change solves the right problem.
Those decisions form a review queue. If completed agent work arrives faster than it can be evaluated, the queue grows. Waiting work becomes stale as the base branch changes. Reviewers lose the context behind each task. Agents are restarted to repair conflicts that existed only because an earlier result waited too long.
This is not an argument for reading every generated line. That already fails with one prolific agent. It is an argument for treating review capacity as a limit on work in progress. Evidence-based review can make each decision cheaper, but it does not make the number of decisions infinite.
A practical limit might be two active implementation tasks and one research task. It might be one. The number depends on the codebase, the strength of its tests, the cost of mistakes and the time available for integration. The useful question is not “How many agents can I start?” but “How many results can I responsibly decide upon before they decay?”
Coordination overhead can erase parallelism
Cursor’s February 2026 multi-agent research provides a useful extreme example. In its first design, equal agents coordinated through a shared state file. Cursor reports that lock contention reduced 20 agents to the throughput of one to three. Later, a single integrator became a bottleneck in front of hundreds of workers. The team eventually used recursive planners, narrow worker tasks and hand-offs travelling back up an ownership chain.
Cursor also reports a peak of roughly 1,000 commits per hour across ten million tool calls during a week-long research run. That is an impressive experiment, but it would be a peculiar target for most software teams. The browser was a research project not intended for external use, and the team accepted temporary breakage. The report argues that this approach would need a final green branch before release; it does not demonstrate a production release process. Copying the headline without copying those operating assumptions would be cargo cult management at considerable token expense.
What I take from the experiment is narrower: coordination architecture affected throughput more than the number of available agents. Shared locks, vague ownership and a central gate all became limiting factors. Adding workers before fixing those constraints made the system busier, not proportionally faster.
Parallelism needs an admission test
Before starting another agent, I would ask whether its task has all of the following:
- A boundary. It owns a defined change surface or a read-only question. “Improve authentication” is not a boundary.
- A known base. We know which revision, specification and interface assumptions it starts from.
- A terminal predicate. Completion is observable: named tests pass, a report answers specified questions, or a particular behaviour is demonstrated.
- A useful failure. If the agent does not finish, its investigation or isolated branch does not obstruct the other work.
- An integration owner. Someone has responsibility for deciding whether and how the result enters the main line.
- Review capacity. There is a realistic slot to inspect the result soon after it arrives.
If two tasks require the same unresolved interface decision, they are not ready to run in parallel. Resolve the interface first. If they will both rewrite the same subsystem, run alternatives as explicit experiments and expect to discard at least one. Calling them independent implementation tasks merely hides the cost.
This admission test also exposes a rejected alternative: starting a fleet and asking it to self-organise around a broad outcome. It can work inside a harness deliberately built for that behaviour. It is a poor default for a normal repository, where ownership is implicit, CI is finite and preserving existing work matters more than keeping every model busy.
A modest form of one-to-many
Multi-agent work does not have to mean an autonomous software factory. Mitchell Hashimoto describes using the last 30 minutes of his day to start research, idea exploration and read-only issue triage. He did not expect speculative branches to become shipping code, and he explicitly prevented triage agents from replying to issues. Later in the same account, he says he preferred one implementation agent at a time.
That combination is more interesting than a universal productivity claim. Parallelism suited work where outputs were independent and cheap to reject. Serial execution suited work where his own attention and confidence were the constraint.
Research is often a good first use for several agents because comparison is the product. Give each one a different hypothesis or source boundary, then ask for evidence in the same format. The losing branches have still reduced uncertainty. Parallel implementation is less forgiving: discarded work is usually just discarded work, and conflicting changes must be reconciled before they provide value.
Set the work-in-progress limit first
One-to-many is valuable when elapsed time matters, the work graph contains real independence and the review loop can keep up. It is wasteful when the fleet exists mainly because the tools make spawning one easy.
My preference is to start with the smallest useful fleet, set an explicit work-in-progress limit, and increase it only after observing where results wait. If agents wait for tasks, that may be fine. If completed tasks wait for human judgement, adding another agent is the wrong optimisation.
The next problem is mechanical but not trivial: giving concurrent workers isolation without losing control of branches, user changes or integration order. That is the subject of the next chapter.