Multi-Agent Systems

Several agents, and the coordination you now own

What are AI agents makes the case that the five workflow patterns are usually the answer and a single agent is already a step past most problems. This page is the step after that, which is rarely the answer and occasionally the only one.

Multi-agent context sharing covers why separate windows help and what they cost: about 15 times the tokens of a chat interaction. That number is the entry fee, and this page is about the topologies you get for it and the failures that come with them.

Four shapes

Orchestrator and workers. One lead decomposes a task and spawns subagents in parallel. The best-documented shape, and the one multi-agent context sharing describes in detail. Right when the subtasks are independent.

A pipeline. Each agent's output is the next one's input. Draft, then critique, then revise. Predictable and sequential, so you get no parallelism, and the failure mode is an error introduced early that every later stage treats as given.

Generator and critic. One produces, another evaluates against criteria, and the loop runs until the critic passes it. Effective where quality is checkable and expensive where it is not, since without a real standard the critic approves on the second pass regardless.

A shared blackboard. Agents read and write common state rather than messaging each other. External memory is the mechanism, and this is the shape to reach for when the work does not decompose cleanly. It is also the hardest to debug, because any agent can have written anything.

What coordination costs beyond tokens

Three costs that do not show up in a token count.

Latency is the slowest path, not the average. Parallel subagents finish when the last one does. A pipeline is the sum of every stage. Either way the user waits longer than any single agent took.

Errors compound. Four agents at 90% each is not a 90% system. If each depends on the last, you are near 65%, and the arithmetic is worse when a wrong answer looks plausible enough to pass along.

Debugging is a trace problem. A bad output came from somewhere in a graph, and without per-agent spans you are guessing. Tracing and logging covers modelling a request as a trace, and multi-agent is where that stops being optional.

The failures are about instructions, not architecture

The documented early problems in Anthropic's system were delegation quality rather than topology: spawning fifty subagents for a simple query, searching on for sources that did not exist, and duplicating work when instructions were vague.

Each maps to something missing from the task description rather than something wrong with the shape. A subagent gets an objective, an output format, guidance on tools and sources, and clear boundaries, and omitting the boundaries is what produces two agents doing the same search.

The general lesson: a multi-agent system fails the way a badly briefed team fails, and the fix is the brief.

When it is worth it

Ask three questions before building one.

Does the work decompose? Parts that can proceed without knowing each other's results. If every step needs the previous one, a pipeline is all you get and a single agent with a loop is simpler.

Is the answer worth 15 times a chat? Anthropic's justification was a research eval where multi-agent beat single-agent Opus 4 by 90.2%, which is the kind of margin that pays for the multiple. Most tasks do not have one.

Can you see inside it? If you cannot trace which agent produced what, you cannot operate this.

If any answer is no, use one agent, or use the workflow patterns that what are AI agents says are usually the answer.

Further reading

• Multi-agent context sharing: the window argument, the token multiples and the delegation contract.
• What are AI agents: the workflow patterns to try first.
• Agent use cases: whether a loop earns its cost at all.
• External memory: shared state for agents that cannot see each other.