When Not to Multi-Agent

A team lead, eager to compress a two-day feature build into one overnight run, spins up four coding agents against the same service: one owns the API layer, one the database migration, one the frontend, one the tests. Four agents, four slices, one commit by morning — the same arithmetic that makes a four-person team of engineers faster than one working alone. By standup, two agents have written incompatible definitions of the same shared type, the frontend agent built against an API shape the backend agent abandoned an hour into its run, and the test agent’s suite fails against all of it. Untangling the four diffs into one coherent change takes longer than writing the feature serially would have. The team didn’t get four times the throughput. It got one difficult merge and three runs whose tokens bought nothing.

This is not a story about a bad prompt or an unlucky model. It is a story about a bet that coding tasks parallelize the way research tasks do — and they mostly don’t. The evidence for the strong version of the multi-agent thesis, that a fleet of agents beats one agent on most work, is real, but it lives almost entirely in a different kind of task: search and research, where each subagent can chase an independent question and hand back a self-contained answer. Coding shares almost none of that shape. This chapter makes the contrarian case first, before the rest of the volume builds the patterns that do work, because the failure mode above is common enough, and expensive enough, to deserve a name before it gets a solution.

What multi-agent actually wins at

Anthropic built one of the first large production multi-agent systems and published an unusually candid account of what made it work and where it didn’t. The pattern is an orchestrator — a lead agent — decomposing a question into independent subagents, each exploring a different angle in its own context window before condensing its findings for the lead to synthesize. The company reports that its “multi-agent research systems excel especially for breadth-first queries that involve pursuing multiple independent directions simultaneously.” The worked examples in that piece are research questions: which company boards overlap, what solar developments exist across a set of counties — the shape of task where an answer to one sub-question doesn’t depend on the answer to another.

The reason that shape parallelizes well is structural, not incidental. Each subagent’s job is to explore in its own context and return exactly one thing: a compressed summary the lead agent can read without ever needing to see the exploration behind it. In Anthropic’s words, “subagents facilitate compression by operating in parallel with their own context windows, exploring different aspects of the question simultaneously before condensing the most important tokens for the lead research agent.” Coordination happens once, at the boundary, in one direction — subagent to lead. Nobody has to negotiate a shared object mid-task, because nothing is shared.

Why code doesn’t hand out narrow return values

A coding subagent’s output isn’t a paragraph the lead can silently absorb. It’s a diff — a change to a shared, typed, tested artifact that every other subagent’s diff must also stay consistent with. A function’s correct shape often depends on a decision made in a different file; a shared type change ripples to every call site; two agents editing adjacent code can conflict in ways two agents each summarizing a different web page simply cannot. Anthropic says as much plainly, about its own architecture: “some domains that require all agents to share the same context or involve many dependencies between agents are not a good fit for multi-agent systems today. For instance, most coding tasks involve fewer truly parallelizable tasks than research, and LLM agents are not yet great at coordinating and delegating to other agents in real time.”

The company’s own documented coordination failures, from the research domain it built the system for, are recognizably the same failure mode coding hits: “one subagent explored the 2021 automotive chip crisis while 2 others duplicated work investigating current 2025 supply chains,” because the task boundaries handed to them weren’t specific enough. Give two coding agents an underspecified split of the same module and the result looks identical — overlapping edits, duplicated discovery, one agent’s assumption invalidated by a decision the other agent made and never surfaced.

The evidence so far

Anthropic’s caveat is one vendor’s account of one system, and this volume’s evidence bar asks for more before treating a claim as established. The more specific, coding-focused research is recent — late 2025 and 2026 — and still thin, but what exists points the same direction. CooperBench, a benchmark published in January 2026 specifically to test whether coding agents can act as teammates, ran over 600 collaborative coding tasks across twelve open-source repositories in four languages and found that “agents achieve on average 30% lower success rates when working together compared to performing both tasks individually.” The paper traces the gap to three concrete failure modes: communication channels “jammed with vague, ill-timed, and inaccurate messages,” agents that “deviate from their commitments” even after communicating clearly, and agents that hold “incorrect expectations about others’ plans and communication.”

A separate late-2025 evaluation of agent frameworks on code-centric software-engineering benchmarks found an even starker gap on program repair: a single-agent framework resolved 54% of SWE-bench Lite issues, while a multi-agent framework resolved 3% on the same benchmark. That particular comparison is confounded — it tests two different frameworks, not the same framework with agent count as the only variable — so it should be read as directional, not definitive. But the paper’s own explanation for the gap matches the coordination story: more agents mean “excessive input tokens that exceed the LLM’s maximum context length, resulting in information loss,” plus errors that compound across handoffs. A third study, from mid-2026, on automatically designed multi-agent systems applied to reasoning benchmarks — a different task domain, worth flagging as such — reports that those architectures were “up to 10x more expensive” than a strong single-agent baseline while performing worse. Three separate studies, three different task domains, the same shape of finding: paying more tokens for coordination and getting less back.

A rough test for whether a coding task parallelizes

None of this means coding tasks never parallelize. It means the ones that do share a specific shape: no shared state, no cross-file coupling, and a result that composes by simple union rather than by negotiation.

The common thread in the right column is Amdahl’s Law, borrowed here as an analogy rather than cited as a direct finding about AI agents: a system’s achievable speedup from parallelizing part of a task is capped by the fraction of the task that has to stay sequential, no matter how many workers get added to the parallel part. A feature that needs one person, or one agent, to hold a coherent, evolving model of how a subsystem’s pieces fit together has a large sequential fraction by construction — no number of parallel agents shortens the part where the pieces must be reconciled in one head. Software engineering learned a human version of this same lesson decades before agents existed. Fred Brooks, managing IBM’s System/360 project, observed that adding people to a late project tends to make it later, because communication overhead among contributors grows faster than the work can be divided. A fleet of coding agents negotiating a shared codebase in real time is not a new problem. It is an old one, running faster and cheaper per mistake.

The token cost of finding out

Even when a coding task does decompose cleanly, multi-agent is buying that decomposition with tokens, and the price is not small. Anthropic reports that its agents use roughly four times the tokens of a single chat interaction, and multi-agent systems roughly fifteen times — a cost the next chapter in this volume develops in full. Volume I’s Session ROI framing applies directly here: token spend has to earn back not just the cost of a serial session but the added coordination cost of the fleet on top of it. When a task doesn’t decompose cleanly, that added spend buys rework, not throughput — the CooperBench finding above is a 30% success-rate cost, not a 30% speed gain.

What Operon’s own multi-agent feature assumes

Before you split the work

1. Ask whether the task’s pieces share a type, an interface, or a file. If they do, the pieces aren’t independent, and parallelizing them just moves a merge task to the end of the run instead of removing it.
2. Reserve fleets for the two shapes that actually hold up: mechanical, identical changes applied across many files with no cross-file coupling, and genuinely unrelated fixes in genuinely unrelated files.
3. Default to one agent, run well, for anything that needs a coherent, evolving mental model of a subsystem — that coherence is exactly what a fleet fragments.
4. When a task does look parallelizable, treat the fleet run itself as a bounded experiment with a judgment step at the end, not a permanent way of working. Chapter 9 develops what that judging looks like at fleet scale.
5. Before scaling a fleet up, price the coordination, not just the tokens. A 30% success-rate loss and a 15x token bill both erase a multi-agent win faster than most retros account for.

The chapters that follow build the patterns that make multi-agent coding worth its cost when a task actually earns it — isolation, task routing, conflict resolution, judging results at fleet scale. None of that changes the starting premise. Most coding tasks are not research tasks, and the fleet is a tool for the narrow slice of work that is.