Multiple agents, and the honest cost

What people mean by it

The usual architecture is an orchestrator that decomposes a task and hands pieces to workers, each with its own prompt, its own tools and its own context, whose results the orchestrator combines.

Sometimes this is better. Often it is a single agent redrawn as a diagram, at three times the cost, and the honest question is which one you have.

The one thing it buys: context isolation

The strongest argument for splitting is not specialisation. It is that each worker starts with a clean, short context.

A single agent researching six suppliers accumulates everything it has read. By supplier four it is carrying 60,000 tokens, every step is expensive, and the material about supplier one is competing for attention with the current question. Six workers each read about one supplier in an 8,000-token context and return a 300-token summary. The orchestrator sees 1,800 tokens instead of 60,000.

That is a real mechanism with real consequences: better attention on each subtask, lower per-step cost, and, because the subtasks are independent, the ability to run them in parallel and turn six sequential minutes into one.

The other genuine wins are narrower. Different tool permissions per worker, so the summariser cannot touch the tool that sends email. A separate critic that reviews the output without having produced it, which catches a real class of self-consistency errors. Parallelism on independent work.

What it costs

Tokens multiply. Each worker pays its own system prompt and tool definitions. Anthropic’s own published account of a multi-agent research system put the token consumption at roughly 15 times a single chat interaction. If your task is worth that, fine: for high-value research it may be. For a support reply it certainly is not.

Errors compound across the seam. The orchestrator’s decomposition can be wrong in ways no worker can detect. Give a worker a badly framed subtask and it will answer it well, which is worse than failing, because the wrong answer arrives with confidence and the orchestrator has no way to tell.

Information is lost at every boundary. A worker’s 300-token summary is a lossy compression of what it learned. The nuance the orchestrator needed may be exactly what was compressed away, and nobody can see that it happened.

Debugging gets much harder. A bad final answer now requires tracing which worker got which subtask, what each returned, and how they were merged. Without per-worker traces this is close to impossible.

Cost and latency become unpredictable. Six workers, each with its own step budget, is a cost ceiling that is the product of your budgets rather than the sum of your expectations.

The test before you build it

Before splitting, answer three questions honestly:

1. Are the subtasks independent? If worker three needs what worker two found, you do not have parallel workers. You have a chain with extra overhead.
2. Can the orchestrator decompose the task reliably? If you cannot write the decomposition rules yourself, the model probably cannot either.
3. Is the context actually large? If a single agent runs comfortably in 15,000 tokens, the main benefit does not apply and you are paying for architecture.

If any answer is no, build one agent with good tools. It will be cheaper, faster and debuggable, and you can revisit this when you have a concrete measurement showing the single agent failing.

The shapes that work

Where multi-agent does earn its place, three patterns dominate.

Fan-out, fan-in. Independent subtasks in parallel, results merged by the orchestrator. Research across sources, checking a document against ten policies, comparing suppliers. The cleanest case, because independence is real.

Generate then critique. One agent produces, a second reviews against explicit criteria with the first agent’s reasoning hidden. Effective for code and for writing. The critic must have its own criteria and must not see the generator’s justification, or it agrees with it.

Router plus specialists. A cheap classifier picks one specialist, which does all the work. Barely multi-agent (it is the routing chain from module two), and it delivers most of the benefit for a fraction of the cost. When someone proposes a multi-agent system, this is usually the version that should ship.

The state nobody designs

One practical warning. Multi-agent systems fail on shared state more often than on reasoning. Two workers writing to the same file, an orchestrator reading a result before the worker finished, a retry that re-runs a subtask whose side effect already happened.

This is ordinary concurrency, and it does not become easier because the participants are models. Give each worker its own workspace, make results immutable once returned, and keep every side effect in the orchestrator where there is exactly one of them.