The Coordination Tax

In one line: splitting the work adds calls that do no work, and only real parallelism buys them back.

What the tax is

Three components, and they are all paid before or around the useful work rather than as part of it.

Decomposition. The supervisor reasons about how to split the goal. One model call, and its prompt carries the whole request.

Dispatch. Deciding which worker gets what, per round.

Assembly. Combining the results, and deciding whether the goal is met. Its prompt carries every worker's output, so it is the largest single call in the system.

None of that produces any of the answer. It is the price of the shape.

And it compounds with depth. Every level of hierarchy adds another decompose-and-dispatch before anything begins, which is the latency argument for wide-and-shallow from the topologies lesson, restated as money.

When parallelism pays it back

The arithmetic worth being able to do out loud.

Sequential single agent: the sum of all steps.

Multi-agent with genuine parallelism: the coordination calls, plus the longest worker rather than the sum, plus assembly.

So the design wins on latency when the parallel saving exceeds the coordination overhead — which requires the sub-tasks to be genuinely independent, and enough of them that the maximum is meaningfully less than the sum.

Two workers whose tasks take similar time save roughly half the work portion and pay full coordination. Five workers save considerably more. One worker saves nothing and pays everything, which is why a supervisor with a single worker is a strictly worse single agent.

On cost, it never wins. Total tokens are the sum of all workers plus the coordination calls, and that exceeds a single agent doing the same work. Multi-agent buys latency and specialisation, and pays in money. Being clear about that trade is worth doing, because designs are often justified on efficiency and the efficiency is not there.

Where the money actually goes

Three places, and only one is obvious.

Worker execution. The visible cost, and usually not the largest surprise.

Context duplication. Shared context sent to every worker is paid per worker. A large system prompt, a policy document, the original request — all multiplied by the fan-out. This is frequently the biggest avoidable cost and the least noticed.

Assembly. The supervisor's final call carries every worker's output, so it is large and it grows with the number of workers.

The mitigation for the second is to send each worker only what its sub-task needs — which is the same discipline as observation reduction in the browsing chapter, and it conflicts directly with the interface lesson's advice to pass the original request to everyone. The resolution is that the request is small and should go to everyone; the corpus is large and should not.

Reducing the tax

Four levers, in order of effect.

Fewer agents. Each one adds a dispatch, an interface, and a share of the assembly prompt. The wide-shallow structure with as few workers as the task needs is cheapest.

A cheaper supervisor where possible. Dispatch and routing are much smaller problems than the work itself, so the coordination calls often do not need the largest model. The assembly call usually does.

Deterministic decomposition. If the sub-tasks are predictable from the request type, choose them in code rather than with a model call. This removes the single largest coordination cost and it is available far more often than it is used — and it is another sign the system may be a workflow.

Don't re-send what has not changed. In multi-round systems, the supervisor's context accumulates. Summarise completed sub-results rather than carrying them verbatim, exactly as in the single-agent loop.

Latency, honestly

Parallelism helps less than the diagram suggests, for three reasons.

The slowest worker sets the pace. With variable sub-task difficulty, the maximum is much worse than the average — the same tail problem as any scatter-gather.

Coordination is serial. Decompose, then dispatch, then wait, then assemble. Those cannot overlap with the work they are organising.

Rounds compound. A system that dispatches, assembles, and dispatches again pays coordination per round, and a critic that rejects once doubles it.

Which produces a practical target: one round of parallel work plus assembly. Systems that iterate over multiple dispatch rounds are usually paying more in coordination than they gain in quality, and the ones that need many rounds are often the ones that should have been a single agent.

The comparison to make

The question to answer before building, and the honest answer is often uncomfortable.

Take the task, estimate a single agent's step count, and estimate the multi-agent version: coordination calls plus per-worker steps plus assembly. Then ask what the second buys — how much latency does the parallelism actually save, and does the specialisation or verification improve the result enough to justify the rest.

If the answer is "it is about the same but it looks better organised", that is a workflow with extra vocabulary. The design that survives this comparison is one where the parallelism is real, or the contexts genuinely conflict, or the verification is genuinely independent.

Next: finding out which agent was wrong.