Multi-agent systems

By the end of this page — you can name the three multi-agent patterns, explain when a *single* agent is the better choice, and estimate why multi-agent costs more than it looks.

One agent is a chef working alone in a kitchen. Multi-agent is a restaurant brigade: a chef, a pâtissier, a runner, a critic. More output — but more coordination, more dishes to taste, and more ways to argue about the menu.

The three common patterns

Pattern	How it works	Best at
🎼 Orchestrator	One “lead” agent splits the task, delegates sub-tasks to workers, merges their results	Big, decomposable jobs (“research 12 sources, write a report”)
🏭 Pipeline	Fixed sequence: agent A’s output feeds agent B’s, then C’s	Repeatable workflows (draft → review → format)
🥊 Debate / swarm	Several agents solve the same task and critique each other (or vote)	Quality-critical outputs where one brain isn’t enough

The orchestrator pattern is the workhorse — Most real systems (including the one reading this sentence's author's tooling) are orchestrator-style: a coordinator that holds the goal and a pool of workers that each hold one sub-goal. It's easier to debug because there's always a single thread of authority.

When ONE agent is the right answer

Be honest with yourself here — this matters more than the patterns above:

The task is sequential and small → one agent, done.
You can’t explain the sub-tasks clearly → you can’t delegate them either; a single agent improvising beats a fleet misdirected.
Budget matters → see below.

Multi-agent is not “smarter”. It’s parallelism + separation of concerns, and it’s only worth it when one of those two is actually the bottleneck.

The cost multiplier nobody mentions

A multi-agent system doesn’t cost N times more — it costs roughly N × N:

each agent carries its own context and system prompt,
every agent re-reads results,
and their messages to each other are also tokens.

Hallucinations and injection multiply too — An agent talking to an agent compounds [hallucinations](/fundamentals/hallucinations/) (agent B trusts agent A's confident wrongness) and widens the [prompt injection](/agents/agent-security/) surface (every message between agents is untrusted text the model can't tell data from instructions). More mouths = more attack area.

A rule of thumb

If one agent can do it in under ~20 tool calls, keep it one. Go multi when the job is genuinely parallel, or when a sub-task is long enough that a fresh context for it beats one bloated conversation.