Multi-Agent Fan-Out and the Token Multiplier

The multiplier you are agreeing to

"Use multiple agents" is the default whiteboard answer, and it is usually wrong. It is not wrong because parallelism is bad. It is wrong because it is proposed before anyone has established that one agent is insufficient, and because the price is rarely stated.

Start with the price, because it is the part you can derive rather than argue about.

Anthropic published both halves of this honestly. Their multi-agent research system burned roughly an order of magnitude more tokens than a single chat interaction, and they shipped it anyway, because for open-ended research that is a fine trade: the breadth is the product. Cognition published the opposite conclusion for their domain and, more usefully, the reason. Both are right. The lesson is the decision rule between them.

When fan-out wins

Three conditions, and you want all three:

1. The work is genuinely parallel. Twenty sources to read are twenty independent reads. There is no ordering, and doing them at once is not a simulation of doing them in sequence, it is the same thing faster.
2. Each subtask is independently verifiable. A worker's output can be judged correct on its own, without knowing what the other workers decided.
3. Breadth beats depth. More surface covered is worth more than more reasoning about less. Research and search are the canonical fits, which is exactly why the published multi-agent success stories are research systems.

Under those conditions the token multiplier is not waste. It is the price of breadth, and you are buying breadth on purpose.

When it loses

Invert the list. Fan-out loses when the subtasks share state, when the decisions interact, or when the output has to be internally consistent. Code changes are the canonical anti-fit, and the reason is worth stating precisely, because it is not "code is hard".

The mechanism is that a subagent does not share the implicit context that made the parent's decisions coherent. Actions carry decisions. A worker cannot do its job without making them, and it makes them alone.

brief given to every worker: "port this module off the deprecated Clock API"

worker A --> billing/invoice.ts    decides on UTC instants everywhere
worker B --> billing/dunning.ts    decides on tenant-local zoned times

Both diffs compile. Both pass their own file's tests. Both reviewers wrote
"clean port". Neither reviewer was wrong.

Together: dunning compares its zoned time against invoice's instant, and the
retry window is off by the tenant's UTC offset. The bug is in NEITHER file.
It is in a decision the brief never made, that two workers each made once.

This is the failure the corpus has never had to handle before. Level 5's "Partial Failure & the Fallacies of Distributed Computing" prepared you for workers that fail: timeouts, retries, compensating actions, a partial result. It did not prepare you for workers that all succeed and collectively contradict each other, because that failure has no error, no exception, and no failed worker to retry. Retrying is in fact the worst response, because both workers were right.

Four topologies, four bills

Table

Every row buys something and pays for it somewhere else. The blackboard is the one that directly attacks the handoff problem, by giving workers a place to see each other's decisions, and it inherits every concurrency problem that comes with shared mutable state.

Topology	Token cost	Latency	The failure it is prone to
Orchestrator and workers	N worker contexts, plus the orchestrator re-reading every report	One worker's run, plus the merge	Workers each succeed and the merge cannot reconcile them
Sequential handoff	One context that keeps growing, so cost rises with the square of the stage count	The sum of every stage, so no parallel win at all	An early wrong decision is inherited by every stage after it
Debate	Two or more full contexts per round, times rounds	One turn per round, rounds in sequence	Confident agreement on a wrong answer, with no natural stopping rule
Shared blackboard	One shared state all workers read, so cheaper per worker than fan-out	Close to orchestrator and workers	Write conflicts and stale reads, exactly like any shared mutable store

Reliability when the workers are models

Fan-out is a scatter-gather, so the hard-won distributed-systems material applies unchanged, with one addition.

Partial failure. A worker can fail, hang, or return something useless. Define aggregation for the missing worker before you need it: does the task fail, or does it return a partial result with the gap named? "Wait for all six" is a decision to let the slowest worker set the deadline and any worker set the failure rate.

Deadlines ladder down. The caller's deadline bounds the orchestrator's, which bounds each worker's, with room left for the merge. A worker with no deadline of its own is a worker that can hold the whole task open.

Budgets ladder up. The LLM Agents lesson's governors (steps, tokens, wall clock, dollars) now exist at two levels: a cap per worker, and a task cap that the sum of the workers must not exceed. Enforce the task cap in the orchestrator, because six workers each individually inside budget can still be six times over the task budget.

Consistency is the new one. For workers that each succeeded, there is nothing to retry and nothing to compensate. The only defenses are upstream: settle the shared decisions before fan-out and put them in every brief, or give workers a shared place to record decisions, or verify the combination rather than the parts. A per-part gate cannot see a combination defect, which is why the integration check belongs before the per-part review rather than after it.

Consistency is also measurable, and it is worth naming the shape of the measurement. tau-bench evaluates tool-using agents across repeated independent trials of the same task and reports pass^k, the share of tasks an agent gets right on all k attempts. Measured pass^k falls steeply as k rises: the same agent, the same task, a different run, a different answer. Fan-out multiplies exactly that variance, because a task built from six independent runs is closer to a pass^6 than to a pass^1.

Interview nuance: the answer that reads as senior is a default to one agent with a stated trigger for fan-out, plus the cost multiplier you accept when the trigger fires. "Twenty or more sources, no ordering between them, each independently checkable, so I fan out and accept roughly a 2x token bill" is a design. Proposing five agents before establishing that one is insufficient is the tell that the candidate is repeating an architecture rather than choosing one.

Recap: fan-out costs a token multiplier you can derive rather than quote, and it earns that multiplier only when the work is genuinely parallel, independently verifiable, and better served by breadth than depth; the failure it introduces is workers that each succeed and collectively contradict, caused by decisions the brief never settled; the four topologies trade cost, latency, and failure mode differently; and reliability needs laddered deadlines, laddered budgets, a defined aggregation for a missing worker, and an integration check that runs before the per-part review.

Sources: How we built our multi-agent research system · Don't Build Multi-Agents · tau-bench · Effective context engineering for AI agents