When Multi-Agent Actually Pays

Multiple agents are a cost, not a default. Clear at least one of six gates first, and split roles only where engineering responsibility genuinely differs.

Multiple agents are a cost, not a default: each adds tokens, a latency path, a failure surface, and ambiguity about who owns the outcome. Pay that only after clearing one of six gates, and split roles where engineering responsibility differs.

Six gates: clear at least one

• Subtasks can be meaningfully parallelized.
• Context should be isolated.
• Tools or permissions must be isolated.
• The work is deployed by separate teams or services.
• A single agent's context cannot hold it.
• Independent review adds a perspective with measurable benefit.

Note the qualifier on the last one: a reviewer agent added to look more rigorous is pure overhead. And many tools are not many agents: one agent with ten tools is one context with one owner, and more tools will not give you isolation.

Does anything new come in?

Beyond the admission gates, the book collapses the value of multi-agent into one test: does the collaboration introduce information a single agent did not have at the moment it generated the answer ai-agent-book.

The table also explains the split between academic and engineering findings. Academic setups usually have several agents discussing one shared piece of context, which introduces nothing new. Systems that work in production almost always carry an external feedback loop — execution, rendering, tool verification. RLEF is the same claim on the training side: iterating against code execution feedback beats drawing many independent samples and picking the best, because each iteration injects a signal that did not exist while the code was being written — compile errors, failed tests, runtime exceptions ai-agent-book.

Hold it against the reviewer you just added. Does it see something the generator cannot? If all it has is the same context, what you bought is a restatement.

Count what you are buying

Do three sums first. Extra tokens, because every agent reloads the shared context. Extra latency, because the slowest branch sets the wall clock. Extra failure surface, because N agents bring their own timeouts, drift, and tool failures.

Then define four things; missing any one turns multi-agent work into several people editing one file: who coordinates, who owns each output, how shared state is read and written, how conflicts are resolved.

The split criterion: different engineering responsibility

Several agents using similar context to make similar judgments and then restating each other's conclusions is pure cost. Splitting pays off only when two conditions hold together: the roles map to stable engineering responsibility, so planning, implementing, and verifying each have an owner, and they disagree about what done means — the planner asks whether a task is verifiable, the worker whether tests pass, the evaluator whether the requirement was met. Creating agents for the sake of roles is the common waste.

Cognition reached the same conclusion from the other side. Their first attempt gave several independent agents a partial context each and let them work in parallel; the decisions conflicted and never composed into a coherent whole. Their principle is to share full context and hand one continuous task stream to a single responsible owner cognition-no-multi. In other words, prove one agent cannot hold the work before you split it.

Three real ways it fails

Cursor started with 20 agents as flat peers coordinating through a shared file, using locks to stop two grabbing the same task. Agents held locks too long or forgot to release them, the lock became the bottleneck, and throughput fell to two or three agents. Worse, with no hierarchy they became risk-averse: small safe changes, nobody took the hard ones, long stretches without progress. A planner and worker pipeline is what worked cursor-scaling-agents.

Anthropic hit a different failure with 16 agents compiling the Linux kernel, which is one giant task: every agent hit the same bug and overwrote each other's fixes, so the sixteen accomplished nothing. They ended up using GCC as a known-correct oracle, compiling most files with GCC and handing only the remainder to Claude's compiler; if the kernel runs, the problem is not in Claude's subset, if it crashes they bisect and shift files back to GCC. Independent tests parallelize naturally. A monolithic task does not anthropic-c-compiler.

One more cost is invisible. On the same 1,266 BrowseComp questions, the unintended-solution rate was 0.24 percent for a single agent and 0.87 percent for multi-agent: 3.7 times higher. Multi-agent does not change the model's tendencies, but the higher token volume and several parallel searchers per round raise the odds that one agent finds leaked material or suspects it is being evaluated anthropic-eval-awareness.

The runtime contract for subagents

Six runtime rules keep background subagents from becoming black boxes. Google's Antigravity team hit exactly that: the orchestrator went dormant until every subagent finished, leaving developers with zero visibility, while unbounded ping-pong burned tokens googleai-subagent.

• Narrow capability switches per task: writes, MCP, spawning subagents, granted by tier.
• Wake reactively: deliver messages into the parent session and trigger a wake, never poll.
• Report in structured payloads (JSON or PROGRESS, ERROR, ABORT) at milestones only.
• Define explicit COMPLETE and TERMINATE flags so message loops cannot ping-pong.
• Inject the parent session id into the initial task; a subagent never guesses the recipient.
• Two levels of circuit breaking: soft abort broadcast and hard termination, so one fatal failure stops the rest spending on a doomed task.

How to use the coordinator

The coordinator owns decomposition, specialist selection, state, budget, permissions, gates, recovery, and summarization. Specialists own a single-domain deliverable with self-contained inputs and outputs, an independent workspace, and domain-level tests.

Two hard constraints: the coordinator must not redo a specialist's core work, or you pay twice for one judgment, and a specialist's tools, data, and write scope must be limited so agents cannot modify the same business object without coordination. Prefer manager-as-tools: expose specialists as tools the primary agent can call, simpler than a coordinator orchestrating a messaging protocol.

Limiting write scope is not enough, because clean files do not imply a consistent result. The book's example is typical: agent A renumbers every figure in a manuscript while agent B revises one chapter and cites figures by their original numbers. They touch different files, so no file-level conflict exists anywhere, and every reference B wrote is broken the moment A finishes ai-agent-book. Optimistic locking stops write conflicts inside one file — record the version on read, compare on write, fail and re-read and redo on mismatch — but it cannot see a cross-file semantic conflict, which needs a validation layer above the storage one. That is why the mainstream shape is working-copy isolation: one branch or one worktree per agent, so parallel edits never touch, and conflicts concentrate at a single merge point you control.

Three questions audit the decision. Do your agents hold different standards for done? How often is shared context reloaded? If you delete one, how much quality do you lose?