Ask three teams how they run a multi-agent system and you'll get three shapes: a pipeline that chains agents in a line, an orchestrator-worker setup where a lead fans out to a swarm of subagents, and a swarm where peers hand control back and forth. The usual framing treats these as a maturity ladder — pipelines for beginners, swarms for the enlightened. That framing is wrong, and it's why so many multi-agent projects fail expensively.

They aren't a ranking. They're one axis, and the axis is context.

The three shapes, precisely#

A pipeline runs agents sequentially: A's output becomes B's input becomes C's input. Context accumulates linearly and nothing is lost, because each stage sees everything upstream. This is the shape behind most reliable production "agents" — the workflow patterns Anthropic catalogs (prompt chaining, routing, evaluator-optimizer) are pipelines wearing different clothes.

An orchestrator-worker system puts a lead agent in charge of decomposition. It breaks the task into subtasks, spawns worker subagents to run them in parallel, and then synthesizes their outputs. Anthropic's Claude Research is the canonical example: a lead agent plans, launches three to five subagents at once, and closes with a separate citation pass. The workers never see each other.

A swarm drops the fixed lead entirely. Peer agents hand control to one another at runtime — OpenAI's Agents SDK handoffs, the pattern its earlier Swarm library popularized. Control flow is dynamic and so is shared state, which makes it the most flexible topology and the hardest to reason about.

The one question that picks for you#

Here is the whole decision, and it fits in a sentence:

How much context can you afford to lose between agents?

Parallel workers are, by construction, blind to each other. When Anthropic's lead spins up five subagents, none of them can see what the others are deciding. That's fine — if the subtasks are genuinely independent and read-mostly. Searching five different corners of the web for facts that don't interact is embarrassingly parallel. But the instant two subtasks must agree on an evolving piece of state — a shared plan, a document being edited, a transaction being assembled — parallelism breaks, because neither worker can incorporate the other's changes. That work has to be a pipeline, or a single agent.

This dissolves the field's most-cited argument. Anthropic reports its multi-agent research system beat single-agent Claude Opus 4 by 90.2% on an internal eval. Cognition's "Don't Build Multi-Agents" argues the opposite: parallel subagents make independent decisions, and independent decisions on the same problem conflict. Both are correct. They're describing opposite ends of the same axis. Anthropic's win comes from independent, read-heavy exploration where isolation costs nothing; Cognition's warning is about interdependent, write-heavy work where isolation is fatal. The rule:

Fan out for read. Single-thread for write.

Choose the topology by where you can tolerate context loss. If subtasks never need to reconcile, use orchestrator-worker and enjoy the parallelism. If they do, serialize them into a pipeline. A swarm is what you reach for only when the routing itself is the problem — dispatch this request to whichever specialist fits — and even then you keep the handoff graph small and the shared state near zero, because a swarm makes both control flow and state dynamic at once.

The bill nobody reads first#

There's a second reason not to treat multi-agent as the default: it is not free intelligence. It's parallelism you rent.

Anthropic's research system burns roughly 15x the tokens of a normal chat. More pointedly, on the BrowseComp benchmark, token usage alone explained about 80% of the performance variance. Read that twice. Most of the multi-agent "win" isn't clever coordination — it's the system spending far more compute on the problem. Which raises the question you should ask before drawing any topology: would a single agent, given a bigger turn budget and a larger context window, get me there for less?

Often it would, and with none of the coordination failures that multi-agent systems add — the lost sub-results, the workers that duplicate each other's efforts, the synthesis step that quietly drops half the findings. Every extra agent is another component that can fail and another context boundary that can leak.

The heuristic, in order#

  1. Start with one agent. Give it the tools and the turn budget. Most tasks end here.
  2. If the task overflows one context window and splits into independent parts, go orchestrator-worker. Parallel read, isolated workers, one synthesizer. Accept the ~15x token bill only when breadth genuinely requires it.
  3. If the parts depend on each other, use a pipeline. Serialize; preserve context; retry the step, not the run.
  4. Reach for a swarm only when routing is the actual problem — and keep the graph and the shared state minimal. Once you've picked a multi-agent shape, the next decision down is who holds the state and control — supervisor vs swarm vs handoffs.

The topology isn't a badge of sophistication. It's an admission about your task: how parallel it really is, and how much your agents can afford not to know about each other. Answer that honestly and the shape picks itself.