Many agents, one task

Why does splitting one capable worker into five specialists sometimes make the result worse?

Specialisation is one of the oldest good ideas we have. Give each worker a narrow job, let them get very good at it, and the whole produces more than the sum. So an obvious move with capable software agents is to build a team: a planner, a researcher, a writer, a critic, an executor.

And sometimes that team produces something visibly worse than one agent doing the whole thing. Not slower — worse. Which is odd, because no individual member got less capable. So something must be lost in the space between them, and that space is worth examining carefully.

Start with what division of labour actually assumes. It works when the subtasks are separable, when the interface between them can be written down, and when each worker's output can be checked. A pin factory satisfies all three. Ask whether an open-ended task does.

Consider what one agent holds while working. Not just the instructions — everything it read along the way, the ambiguity it noticed in the request, the approach it tried and abandoned, the tone it settled on, the half-formed sense of what the user actually wants. Almost none of that is written down anywhere. It is the working state of the task, and it is enormous.

Now hand the task to a colleague. What crosses the gap? Only what is serialised into the message. Everything else is lost, and the receiver — being competent — fills the gap by re-deriving it. Here is the thing to notice: re-deriving is not the same as recovering. The second agent makes its own reasonable assumptions, and they need not match the first's. Nothing errors. You simply get two halves of a piece of work built on quietly different premises, and the seam only shows in the output.

That is handoff cost, and it is not a fixed overhead — it scales with the ambiguity of the task. This is why multi-agent designs work best on well-specified subtasks and degrade fastest on the ones where the judgement is the work.

Then compounding. Each step in a chain has some chance of preserving what mattered. Those chances multiply, and multiplication of numbers below one is brutal: a step that goes right 95 times in a hundred yields about 77 percent over five steps and 54 percent over twelve. Adding a specialist adds a factor to that product, so it must contribute more than it costs — and the cost is paid by every downstream step, not just its own.

Third, coordination is real work that someone has to do. A decomposition must be invented, subtasks dispatched, results merged. Merging is the part that is quietly hardest: if two agents return conflicting findings, deciding which is right requires understanding both problems, which is often the whole task again. A coordinator that merely concatenates has not merged; it has deferred the contradiction to the reader.

Fourth, the resource cost is not small. Each agent re-reads the context it needs, so the same material is paid for repeatedly. Anthropic's published account of its multi-agent research system reports token consumption far above that of an ordinary single-threaded chat — roughly an order of magnitude — which is fine when the task justifies it and indefensible when a single agent would have done.

So when does it pay? The pattern that consistently works is breadth: many genuinely independent lookups or explorations, where subagents share nothing but a question and return findings that do not need to be reconciled with each other. Isolation is a second good reason — an agent with narrow tool access as a containment boundary. And context pressure is a third: when a task genuinely does not fit in one window, splitting it is not a preference but a necessity.

It is worth saying plainly that the field disagrees about how far this goes. Cognition published an essay in 2025 arguing against multi-agent architectures for most work, on precisely the grounds above — fragmented context yields conflicting decisions — while others report strong results from agent teams on search-shaped problems. The disagreement is live, and anyone claiming it is settled is ahead of the evidence.

Three refinements.

First, the failure is not that agents are bad at their jobs. Every specialist may perform its part better than the generalist would have. The loss lives entirely in the interfaces, which is why adding a better agent to a badly-jointed pipeline often changes nothing.

Second, the lever that actually helps is narrowing and checking the interface, not tuning the agents. If a subtask's output has a checkable shape — code that compiles and passes tests, JSON that validates, a claim with a citation that can be fetched — then handoff loss becomes visible instead of silent, and the compounding curve flattens because failures are caught in the step that caused them. Tasks whose outputs can only be judged by another model are exactly the ones where splitting hurts most.

Third, a misconception worth correcting: a human organisation chart is not a good template. Real teams are held together by constant informal repair — the corridor question, the shared history, the person who notices two colleagues have diverged. Copying the boxes without that repair layer copies the structure and leaves out the thing that made it work.

• Context engineering: what actually belongs in a handoff message, and how to write one that survives.
• Verifiable subtasks, and why code and structured data are the friendliest ground for agent teams.
• Orchestrator patterns, and the difference between merging results and concatenating them.

Every term the collection defines is gathered in the glossary.