The Economics of Parallelism

A team migrating an internal service off a deprecated framework discovers, this week, that its coding agent can run five instances at once, each assigned a different module. Five terminals open, five meters ticking. The instinct is almost mechanical: more agents, more surface area covered, done sooner. Nobody on the team asks the one question that would tell them whether this is a good idea, which is what it is buying them per dollar that a single agent working the same five modules in sequence — or the same agent given five times the budget to iterate on one module until it is right — would not have bought instead.

That question has an answer, and it is not the intuitive one. Multi-agent architectures do not usually fail by producing bad results; when a task genuinely fits them, they produce measurably better ones. They fail, when they fail, by being a spend decision nobody made on purpose — the bill arrives sized like a small compute cluster’s, for work a patient single agent could plausibly have done for a third of the cost. The previous chapter in this volume made the contrarian case that most coding tasks decompose poorly into independent parallel work. This chapter assumes that case is sometimes wrong — that a task genuinely does parallelize — and asks the harder question underneath it: even then, when is paying for it worth it?

What multi-agent actually costs

Anthropic’s own engineering team, describing the multi-agent research system behind Claude’s research capability, published the clearest public accounting of this cost that exists. In their data, ordinary agentic tool-use sessions run about four times the tokens of a single chat turn; multi-agent sessions, with a lead agent decomposing work across parallel subagents, run about fifteen times the tokens of a chat turn. Fifteen times is not a rounding difference from four times. It is the difference between a coffee and a catered lunch, per unit of finished work.

The same analysis contains a more interesting number. Across Anthropic’s internal evaluation, three factors explained ninety-five percent of the variance in how well the multi-agent system performed a given task — and token usage by itself explained eighty percent of that, ahead of both tool-call count and model choice. Put plainly: within their architecture, spending more tokens was overwhelmingly the thing that made a run perform better. That is not what most engineering intuition expects. Token spend is usually treated as the thing to minimize once quality is achieved, on the assumption that architecture and prompting, not sheer volume, separate a good run from a bad one. For the class of research tasks Anthropic measured, the data says otherwise.

The double edge

That finding cuts two ways, and a chapter presenting only one side of it would be doing the reader a disservice. The generous reading: more tokens genuinely buy more capability, in aggregate, so a team spending fifteen times as much on a multi-agent run is not lighting money on fire — it is closer to paying for a fifteen-times-larger machine and getting a fifteen-times-larger machine’s output. Anthropic states the resulting requirement plainly: multi-agent systems are economically viable only for tasks whose value clears that higher bar. The stingier reading, and the one most cost dashboards miss entirely, is that an 80% correlation between spend and performance says nothing about whether multi-agent spend is the best way to buy that performance, for this task, at this budget. It says spending more tends to help. It does not say that fifteen parallel agents is a better fifteen-times spend than one agent given fifteen times the iterations, the context, or the verification passes.

That comparison — same budget, different shape — is the actual decision, and it rarely gets made explicitly. A separate line of research measured the other axis directly: giving a single model many repeated attempts at the same coding problem, with automatic verification to pick a winner, produces a coverage curve — the odds that at least one attempt is correct — that climbs log-linearly with the number of samples across several orders of magnitude, on problems cheap enough to check automatically, like passing a test suite. That is depth bought with the same kind of token spend multi-agent buys with breadth, and it has its own diminishing-returns curve, just a differently shaped one, contingent on having a verifier cheap enough to run at that volume. A team with a fixed token budget for a hard bug is really choosing between two spending shapes, not between spending and not spending. The Library’s first volume named the ratio that should decide it — Session ROI, the value a unit of AI-assisted work creates measured against what was invested to get it — sitting inside the larger accounting of the AI Cost Iceberg, whose submerged mass of review time, coordination, and rework grows with every additional agent’s output waiting to be checked.

The measurement problem

The caution here is the same one this Library raised in Volume I about single-agent speed claims. Engineers’ felt sense of whether five agents helped is exactly the kind of judgment a randomized trial found unreliable in a single-agent setting, where measured productivity and believed productivity diverged by roughly forty points — developers using early AI tooling finished slower while confidently reporting they had gone faster. There is no reason multi-agent self-assessment would be more trustworthy. If anything, five simultaneous terminals make the feeling of moving faster easier to have and harder to verify, because there is more activity on screen and less time to check any one thread of it before the next status update arrives.

A fixed-budget comparison sidesteps that unreliable instrument entirely, because it does not ask anyone how a session felt. It asks what actually shipped, at what cost, run against the alternative the team never tried. Few teams keep that record, for the ordinary reason that running a task twice — once wide, once deep — looks like waste in the moment, even though it is the only way to learn which shape of spend this task rewards. A team that never runs the comparison is left with the same instrument the METR trial discredited: a confident guess about which approach felt more productive.

Where parallel spend stops paying

Spend a five-agent budget on a task with five genuinely independent modules, and the return scales close to linearly, because there is close to nothing for the agents to coordinate about. Spend the same budget on a task where two of those five modules share a file, a data model, or an assumption, and the picture changes. Anthropic’s own account of building the research system describes agents duplicating work, leaving gaps, or failing to find necessary information without carefully scoped task boundaries — in one recorded case, three subagents investigating a supply-chain question independently re-derived the same 2021 chip shortage instead of splitting historical research from current research between them. That is not a prompting bug. It is coordination cost, and it is the same cost that has limited parallel speedup in computing since Gene Amdahl described it in 1967: however many processors — or agents — a task is handed, the portion of the work that cannot be split apart caps how much all the splitting can buy, and every dependency between parallel workers hands back a slice of that uncappable portion.

A group of researchers made this connection formally in early 2026, arguing that language model teams inherit the same coordination costs — communication overhead, shared-state conflicts, the price of keeping several workers’ understanding of a task in sync — that have constrained parallel and distributed computing for decades, and that questions like optimal team size stop being guesswork once framed that way. It is the same argument, from a different direction, as this volume’s own case against reflexive multi-agent coding: Anthropic’s engineers concede outright that most coding tasks involve fewer truly parallelizable pieces than research does, precisely because code shares files, types, and running state in a way that independent research questions do not. Five agents editing five files that import from one another are not five independent workers. They are five workers reading each other’s half-finished sentences.

The verification tax

Verification cost deserves its own line, because multi-agent output does not review itself. Industry-wide telemetry already shows AI assistance nearly doubling pull-request throughput while organizational delivery metrics stay flat and code review time grows by more than ninety percent — a bottleneck that moves to human reviewers exactly when AI output increases, on ordinary single-agent sessions. Multiply the output with five parallel agents instead of one, and, absent a review pipeline built for that volume, the review queue is the part of the AI Cost Iceberg that grows fastest — often faster than the token bill that triggered it.

This is the quiet reason a task can pass every test in the decomposability column and still be a bad candidate for five parallel agents: the five diffs still land on one reviewer, at one time, and reviewing five independent changes rarely takes a fifth of the time reviewing one does. A parallel run that halves wall-clock time on the agent side can still be a net loss once the review queue is counted, if nobody widened the verification step to match the wider generation step.

The fixed-budget question

None of this is an argument against multi-agent work. It is an argument for asking one question before spinning up the second agent, let alone the fifth: given this budget, what is the highest-value way to spend it on this specific task? The table below is not a formula — nothing here reduces to one — but it is the checklist that question decomposes into.