Multi-Agent Orchestration: When One Isn't Enough

The reflex when one agent is struggling is to add another. It rarely helps, and the reason is structural rather than accidental. The public argument about multi-agent systems is loud and split in two. One camp says swarms of agents will replace whole teams, the other says never build them at all. Both are describing real experiences, and both have taken a single task shape and turned it into a universal law. The operator read is that the two famous positions do not actually disagree. Anthropic reported a multi-agent research system that clearly beat a single agent on broad, read-heavy research. Cognition argued, just as credibly, that for building software a single coherent thread beats a swarm almost every time. Put them on the same axes and the contradiction dissolves. Multi-agent wins when the subtasks are independent and read-heavy, and it loses when they are coupled and write-heavy.

The cost side is what turns this from an architecture question into an economic one. Anthropic's multi-agent system used roughly 15 times the tokens of a single chat, and token usage alone explained about 80% of the performance variance across their evaluations. That reframes everything. You are not asking whether the design is elegant, you are asking whether this task is worth a 15x bill, and for routine work the honest answer is no. Multi-agent buys you two things and neither of them is raw intelligence. It buys coverage, because five workers explore five branches at once, and it buys wall-clock, because they do it in the time of one. If the task does not split into independent branches whose results you will simply union, you are paying 15x for work you will have to throw away and redo in order anyway.

When it does fit, the shape that ships is orchestrator-workers. A lead agent breaks the task into self-contained briefs, hands each to a worker with its own clean context, and then, the part everyone underestimates, reconciles what comes back. Spawning is the easy ten percent. The ninety percent is synthesis. The orchestrator never sees the workers' raw context, only their returned outputs, so the whole thing holds together only when each worker returns a structured artifact against a known shape instead of a wall of prose the orchestrator has to re-read and re-decide. Delegation here is really task-brief authoring. A worker handed "research X" with no scope does redundant or divergent work, the same way a vague instruction to a new hire does.

The signature failure is decision fragmentation. Hand two workers two halves of the same artifact and each makes a locally reasonable choice that is globally inconsistent. Two halves of a UI built in parallel come back with different button styles, different spacing, different assumptions, and the merge is incoherent in a way that costs more to untangle than the parallelism ever saved. Isolation is free when workers are reading and expensive when they are writing, because writing embeds decisions that have to stay consistent across the whole. The second failure is quieter. The orchestrator itself fills up. Every worker summary it holds eats its own context budget until the captain starts losing the thread, which is the exact problem the fan-out was supposed to solve, reappearing one level up. The way out is to keep the orchestrator lean. Workers write their findings to a file the orchestrator reopens per worker, so it reads only the fields it needs for synthesis instead of carrying twenty full responses in its window at once. And the most common failure is the plainest one, reaching for a swarm at all when a single agent with one tool call would have done the job for a fifteenth of the cost.