Agent Orchestration Patterns: Supervisor, Pipeline, Swarm

Agent orchestration patterns fall into three core shapes. A supervisor pattern has one lead agent plan the work and route it to specialist subagents. A pipeline runs agents in a fixed sequence, each handing its output to the next. A swarm lets peer agents coordinate directly, with no central controller. There is no universally best pattern here, only the one that matches how much unpredictability your system can absorb.

I have shipped versions of all three, and I have also shipped the fourth pattern nobody names on a slide: one agent, no orchestration, because the task didn't need a team. That's usually the cheapest option and often the correct one. Here's how to tell which shape fits your problem, with the trade-offs each one hides until production.

Key takeaways

• Three orchestration shapes cover almost every production system: supervisor, pipeline, swarm. Pick by failure tolerance, not by how impressive the architecture diagram looks.
• Anthropic's orchestrator-worker research system beat a single Opus 4 agent by 90.2%, but the multi-agent version burns roughly 15x the tokens of a single chat interaction to get there.
• Token usage alone explains 80% of the performance variance on Anthropic's BrowseComp evaluation. Most of what looks like "smarter coordination" is spend, not architecture.
• Pipelines buy predictable cost and easy debugging; supervisors buy flexibility at the cost of a routing bottleneck; swarms buy parallelism at the cost of conflicting work.
• The most common orchestration mistake is adding agents before the task has earned them. A single well-scoped agent beats a five-agent swarm on any task that doesn't genuinely parallelize.

If you're deciding whether to add orchestration at all, start one level up with what multi-agent systems are for, then come back here to pick the shape.

What is agent orchestration?

Agent orchestration is the layer that decides which agent runs, in what order, with what inputs, and how their outputs recombine into a final result. It sits above any single agent's own reasoning loop. One agent decides how to solve its task; the orchestration layer decides which agent gets the task in the first place, and what happens to the answer once it comes back.

Every multi-agent system needs an answer to three questions: who plans, who executes, and who resolves disagreement between outputs. Supervisor, pipeline, and swarm are three different answers to those same three questions.

The supervisor pattern: one agent plans, others execute

In a supervisor pattern, a lead agent owns the plan. It breaks the task into subtasks, assigns each to a specialist subagent, and decides what to do with the results, whether that means combining them, discarding one, or asking a subagent to redo its part.

OpenAI's Agents SDK documentation formalizes this as LLM-orchestrated control flow: the model plans dynamically instead of following a script fixed in code. It names two concrete versions of the pattern. In "Agents as Tools," a manager agent keeps control of the conversation the whole time and calls specialist agents the way it would call any other tool, then owns the final combined answer. In "Handoffs," a triage agent transfers the active turn to a specialist outright, and that specialist now owns the response directly (OpenAI Agents SDK docs).

Picture a support-triage system built this way: a supervisor reads an incoming ticket, decides it's a billing question mixed with a bug report, routes the billing half to a specialist that knows the payments API and the bug half to one that can read stack traces, then merges both replies into one message to the customer. That merge step is where supervisor systems either shine or quietly fail, because nothing forces the two specialist outputs to agree with each other.

The pipeline pattern: fixed, sequential handoffs

A pipeline runs agents in a predetermined order. Agent A always finishes before agent B starts. Agent B's input is always agent A's output. There's no planning step and no dynamic routing decision at runtime, because the flow was fixed in code before the task ever started.

This is what OpenAI's docs call code-orchestrated flow, chosen specifically to make execution "more deterministic and predictable, in terms of speed, cost and performance." You trade the model's flexibility to improvise a plan for a flow you can test, time, and price in advance.

A document-processing pipeline is the clean example: an extraction agent pulls structured fields from a PDF, a validation agent checks those fields against a schema, and a formatting agent turns validated output into the final report. Nothing in that chain needs to be re-planned per document. It needs to run the same way ten thousand times, and the tenth-thousandth time it should fail loudly on the exact document that broke it, not silently reroute around the problem.

The swarm pattern: peer agents, no central controller

A swarm has no lead agent. Peer agents coordinate directly, passing messages or partial results to each other and converging on an answer without anyone holding the master plan. AutoGen, one of the earliest and most-cited frameworks in this space (Microsoft Research, first submitted August 2023), built its core abstraction around exactly this: customizable, "conversable" agents that talk to each other in natural language to accomplish a task, rather than following a rigid supervisor or a fixed sequence (Wu et al., 2023).

Swarms fit tasks that genuinely decompose into independent, parallel work with a natural point of convergence. Imagine a research task where three agents each investigate a different hypothesis in parallel, then compare notes to settle on the strongest one. Nobody had to assign the hypotheses in advance, and the agents didn't have to wait on each other to start.

The cost is coordination. With no supervisor to arbitrate, two peer agents can duplicate the same work, or worse, produce two answers that quietly disagree and nobody's job is to notice.

Orchestrator-worker at scale: what Anthropic's research system got right, and what it cost

Anthropic's own multi-agent research system is the most instrumented public example of the supervisor pattern working at scale, and the most honest about its price. The architecture is orchestrator-worker: Claude Opus 4 as the lead agent, Claude Sonnet 4 running as subagents, typically three to five spawned in parallel per research task.

On Anthropic's internal research evaluations, that setup outperformed a single-agent Opus 4 baseline by 90.2% (Anthropic engineering blog). That's a real, large gain, not a rounding error.

It's not free. Anthropic reports that agents typically use about 4x more tokens than a single chat interaction, and multi-agent systems use about 15x more tokens than a chat interaction to get that gain. On their BrowseComp evaluation, token usage alone explains 80% of the performance variance, with model choice and tool-call count accounting for most of the rest.

That number should change how you read every multi-agent case study you encounter, including this one. Before you credit an architecture for a performance gain, ask how much of it you could have bought by giving one agent a bigger token budget instead.

If you're evaluating whether an orchestrated system is worth building for your own workload, this is the exact kind of question a team that builds agentic systems for a living should be running against your traffic before you commit to the architecture, not after.

LLM-orchestrated vs. code-orchestrated: choosing your control flow

Underneath supervisor, pipeline, and swarm sits one more fundamental choice: does an LLM decide the flow at runtime, or does code decide it in advance? This is the axis OpenAI's docs draw directly.

Supervisor and swarm patterns are usually LLM-orchestrated: the routing decision itself is a judgment call the model makes. Pipelines are usually code-orchestrated: the sequence was decided once, by a human, and never revisited per task. Most production systems I've seen end up hybrid: code-orchestrated for the 80% of the flow that's predictable, LLM-orchestrated for the one decision point that genuinely needs judgment, like triaging an ambiguous request before a fixed pipeline takes over.

The failure mode nobody mentions: when orchestration overhead isn't worth it

Every orchestration pattern assumes the coordination overhead is worth paying. Often it isn't. A single well-scoped agent with a clear task and enough context window beats a three-agent supervisor system on any task that doesn't actually decompose into independent parts.

I've watched teams build a supervisor to route between "the summarization agent" and "the extraction agent" for a task that was one prompt with two instructions in it. The supervisor added a routing decision, a second model call, and a new failure mode, an agent that could be misrouted, for zero gain over asking one agent to do both steps in sequence.

The tell is simple: if your subagents never run in parallel and never disagree with each other, you don't have a multi-agent system. You have one task, artificially split, paying orchestration tax for no orchestration benefit. The supervisor pattern also carries a structural cost even when it's the right call: the supervisor itself becomes the single point of failure. It's the same "reviewer becomes a bottleneck, then a rubber stamp, then a liability" problem I've written about for human-in-the-loop review, one layer up. Add enough subagents and the supervisor's routing logic becomes the thing that breaks first, not the specialists underneath it.

Sequential handoffs between agents carry their own version of this cost, which is why it's worth reading how handoffs fail before you wire two agents together and assume the second one will trust the first one's output correctly. I go into that failure mode directly in agent-to-agent communication, and the mechanics of how any single agent decides to call a tool at all, the building block every one of these patterns depends on, are in tool use and function calling.

How to choose the right pattern for your system

Match the pattern to your failure tolerance and your task shape, not to what looks most sophisticated in a diagram.

• Choose a single agent when the task is one coherent job, even a complex one, and nothing genuinely parallelizes. This is the default. Earn your way out of it.
• Choose a pipeline when the steps are known, sequential, and repeat at volume. You want predictable cost and a flow you can test end to end before it ever sees production traffic.
• Choose a supervisor when the task decomposes into distinct specialist skills, but one place still needs to own the combined result and resolve conflicts between subagent outputs.
• Choose a swarm when subtasks are genuinely independent, can run in parallel with no shared state, and converge naturally at the end, and you can tolerate occasional duplicated work as the price of that speed.

Before any of that, run the arithmetic Anthropic's data forces on you: what does the token multiplier cost at your volume, and is the quality gain worth it compared to a bigger budget on one agent? For a workload running thousands of times a day, a 15x token multiplier is a P&L line, not an engineering footnote.

Frequently asked questions

What is the difference between a supervisor agent and a pipeline of agents?

A supervisor decides the plan and routing at runtime, based on the specific task in front of it. A pipeline follows a fixed, pre-decided sequence every time, with no runtime planning step. Supervisors handle unpredictable tasks better; pipelines are cheaper and easier to test because the flow never changes.

When should I use a swarm pattern instead of a supervisor pattern?

Use a swarm when subtasks are genuinely independent, can run in parallel without shared state, and converge naturally at the end. Use a supervisor when one place needs to own the final answer and resolve conflicts between specialist outputs. If your agents would otherwise duplicate work or disagree with no referee, you need a supervisor, not a swarm.

Does adding more agents to a system actually make it perform better?

Sometimes, and less than the architecture diagrams suggest. Anthropic's orchestrator-worker system beat a single agent by 90.2% on internal evaluations, but token usage alone explained 80% of the performance variance on their BrowseComp evaluation. Much of the gain from "more agents" is a gain from more tokens spent, which you can sometimes buy more cheaply with one agent and a bigger budget.

How much more does multi-agent orchestration cost compared to a single agent?

Anthropic reports that agentic single-agent usage runs about 4x the tokens of a single chat interaction, and multi-agent systems run about 15x. Treat that multiplier as a real cost input before you commit to an orchestrated architecture, not a detail to check after launch.

Where this leaves you

Agent orchestration patterns aren't a maturity ladder where swarm beats supervisor beats pipeline beats a single agent. They're four different bets on where unpredictability lives in your task, and each one charges a specific, knowable price for the flexibility it buys. Pick the cheapest pattern that still covers your actual failure modes, then measure whether the next pattern up earns its token bill before you build it.

I go deeper on building agents that hold up past the demo, including how to instrument the supervisor layer itself, in Agents That Actually Work. Read that when you're ready to build the one pattern that fits your failure tolerance, not the one that looked best in a proposal.