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.

How much coordination is enough: one measurement

Anthropic's Frontier Red Team ran a controlled comparison: give 45 agents each a virtual machine and a shared forum to find vulnerabilities in 15 open-source projects and review each other's work, with an arbitration agent deciding; the control group sent independent agents to scan different code regions. The coordinated swarm spent 27 million tokens and found 266 vulnerabilities; the independent parallel agents spent 6.5 million and found 21 anthropic-multiagent-systems.

That number cannot be read as "coordination always wins." When the coordinated group was restricted to the same core directories as the control, the two methods were about equally efficient per token; and only 12 vulnerabilities overlapped between the two groups — the coordinated swarm steered attention toward wherever it judged the best digging to be, built its own tooling, and divided labor spontaneously. The conclusion is that coordination and brute force complement each other: first sweep deterministic ranges with cheap uncoordinated parallelism, then release agents where nobody has drawn the boundaries.

The same experiment tested prompt interventions too: telling agents which team they belong to (core programming, art, testing), or appointing a "CEO" to delegate hierarchically, had almost no effect on the outcome. Coordination quality is a property of the model generation — early models resolved conflicts by giving up, middle generations "resolved" conflicts by each owning a file without sharing, and only the newest generation achieves high sharing and high throughput at once. Counting on prompt engineering to make up for coordination ability is betting system quality on model capability.

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.

There is also a failure mode that humans do not have: agents sharing the same context, scaffolding, and model are low-variance — however large the action space, they tend to make the same choices. If one agent judges wrongly, they are likely all wrong together, and a single case becomes a systemic failure. So "send a few more agents to check each other" is not cross-validation: change the context starting point, change the model, or back it with external evidence anthropic-multiagent-systems.

When to fold subagents back into the main loop

The reverse of splitting holds too: a subagent you already extracted does not have to live forever. Anthropic saw the same pattern across enterprise deployments — one subagent per team, one per problem type, until the architecture becomes a copy of the org chart; the outcome is hundreds of overlapping subagents, a system prompt stitched together from every team's sentences, and evals that are unvetted and over-optimized for each subtask. In their comparisons, a single agent with skills and progressive disclosure outperformed the subagent design on quality, one customer's single loop ran roughly twice as fast, and tool choice degrades once you exceed roughly 30–50 tool definitions anthropic-subagent-folding.

Only three conditions justify keeping a subagent: the single loop shows measurable degradation from context bloat; multiple tasks genuinely need fresh context windows that can be discarded once done; or a single agent struggles to pick tools or the system prompt contains conflicting rules. When none holds, fold it back — prompts become skills, API calls become tools, one subagent at a time, compared with an end-to-end eval before and after. Do not judge by the total score alone; look at which tasks flipped: one team folded a subagent, latency dropped, and a previously passing process broke — the main agent answered with the order-lookup tool itself and stopped asking the shipping specialist anthropic-subagent-folding.

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?

Three collaboration patterns that already work

Role separation. A planner decomposes the task into verifiable subtasks, a generator implements one at a time, an evaluator independently runs tests and accepts against the requirement. Two disciplines: the evaluator must not merely repeat the generator's self-assessment (otherwise you pay twice for the same optimism), and subjective criteria get converted into checkable checklists before being handed over. Overhead this heavy only fits tasks complex and valuable enough.

Fan-out plus adversarial review. The Claude Code team shaped code review into this pattern claude-code-team — fan out widely to collect candidate issues (fan-out produces more information than a human can consume), then run multi-perspective adversarial review over each one to filter false positives, with a deterministic for-loop guaranteeing the same checks apply to every item — "trust in the workflow comes from the deterministic loop." Humans review only the filtered set that genuinely deserves attention. The pattern carries to performance hunting and multi-option research: fan-out trades compute for coverage, but the fanned-out information must be filtered back, or you have only moved the noise to a new address.

The kanban as control plane. The orchestration system does not have to be built. OpenAI's internal Symphony gives every Linear open task its own agent, auto-restarting on crash; the entire "orchestration system" is a spec document (tool usage included) that the agents implement themselves; one more gate — request_changes — forces agents to address existing review comments before new tasks are assigned, stopping task pile-up openai-symphony. No central scheduler, no message bus, and some teams saw landed PRs up 500%. When you catch yourself writing orchestration code for multiple agents, first check whether the project management tool at hand can be that control plane directly.