Agentic Workflow Patterns: Supervisor, Swarm, or Pipeline

Every few weeks someone ships a diagram with a dozen little robot icons wired together, and it gets thousands of likes. Orchestrators, routers, critics, planners, a swarm of specialists all buzzing in parallel. It looks like the future. It usually is not the answer.

I have built enough of these to have a strong opinion, so here it is up front. There are four shapes people reach for when they build agentic systems, and for most real work you want the simplest one that clears the bar. Three of the four are things you probably do not need. The interesting part is that the company with the best public data on this, Anthropic, basically says the same thing, and then backs it with numbers that undercut half the hype.

The four shapes, from boring to flashy

Let me name them the way I think about them, from least to most autonomous. Boring is a compliment here.

• Pipeline. Fixed steps, one after another. The output of step one feeds step two. Anthropic calls this prompt chaining. No agent decides anything, you decided the path in advance. Draft, then critique, then rewrite. That is a pipeline.
• Supervisor. One central agent takes the request, picks which worker handles it, and stitches the results back together. Anthropic calls the general version orchestrator-workers. Every request flows through the boss.
• Swarm. No boss. Agents hand off control directly to each other, and only one is active at any moment. A billing agent decides the question is really about refunds and hands the whole conversation to the refunds agent. Decentralized routing.
• Full autonomy. An agent that plans, acts, observes, and re-plans in a loop with no predefined path at all. This is the one the demos sell. It is also the one that fails in the most creative ways.

Anthropic's Building Effective Agents guide from December 2024 is the cleanest map of this space, and it names exactly five workflow patterns: prompt chaining, routing, parallelization, orchestrator-workers, and evaluator-optimizer. The guide draws a hard line I wish more people respected. Workflows are LLMs orchestrated through predefined code paths. Agents are LLMs that dynamically direct their own process and tool use. That line is the whole game. The more you cross to the right, the more power you get and the more ways you get to fail.

Start with the simplest thing, and mean it

Anthropic's core advice is blunt: start with the simplest possible solution and only add agentic complexity when it demonstrably improves outcomes. For a lot of applications, a single optimized LLM call with retrieval and a few in-context examples is enough. That is not a warmup before the real architecture. For many products, it is the architecture.

I read that as a dare. Before you draw the swarm, prove a single call loses. Most teams never run that experiment, because the multi-agent diagram is more fun to build and much more fun to tweet. The cost of skipping the experiment shows up later, in a system nobody can debug.

The uncomfortable data: it's the tokens

Here is where it gets good. Anthropic built a real multi-agent research system, with Claude Opus 4 as the lead orchestrator and Claude Sonnet 4 as the subagents, and it beat a single Claude Opus 4 agent by 90.2% on their internal research eval. That is a huge margin. If you stopped reading there, you would go build a supervisor tomorrow.

Keep reading. That same system burns roughly 15x the tokens of a normal chat interaction. Single agents already use about 4x the tokens of chat, so the multi-agent setup is expensive on top of expensive. And the punch line is this: Anthropic found that token usage alone explained about 80% of the performance variance on their BrowseComp evaluation. Model choice and number of tool calls explained most of the rest.

Sit with that. Most of the multi-agent win is not coming from the clever coordination. It is coming from the fact that you threw a lot more compute at the problem. A supervisor with five subagents reading in parallel simply consumes and reasons over far more tokens than one agent working alone, and raw compute is doing the heavy lifting.

This reframes the whole decision. The question is not “is multi-agent smarter.” The question is “is this task worth 15x the tokens, and could I get most of the same gain by just letting one agent run longer or read more.” For a high-value research task where the answer is worth dollars, spend the tokens. For a support bot answering the same forty questions all day, you are lighting money on fire to serve a diagram.

Where the parallelism genuinely pays

I do not want to be unfair to the supervisor pattern, because it has one real superpower: parallelism on read-heavy work. In Anthropic's system the lead agent spawns 3 to 5 subagents that run at the same time, and parallel tool calling cut research time by up to 90% on complex queries. When a task splits cleanly into independent chunks, like researching six companies at once, running them in parallel is a genuine win you cannot get from a single sequential agent.

Notice the shape of the task, though. Research fans out. Each subagent goes off, reads its own slice, and reports back. They do not need to agree with each other along the way, and only the lead writes the final answer. That is the friendly case for multi-agent, and it is not an accident that Anthropic's flagship example is exactly this. Read wide, then synthesize once.

The case against the swarm

Now the other side, and it is a strong one. Cognition, the team behind Devin, published a piece called Don't Build Multi-Agents. Their argument is that parallel subagents make systems fragile because each one acts on its own implicit assumptions, and those assumptions quietly conflict. Two agents both confidently do half a job, and the halves do not fit. Their prescription is a single-threaded agent that holds the full context, with a “single writer” where only one agent ever produces the final output.

That single-writer idea is the important one. The moment two agents both write to the final answer, you inherit a distributed-systems problem inside your prompt. Consistency, ordering, who wins a conflict. LLMs are already nondeterministic. Wiring several of them into a shared output is asking for the kind of bug that only shows up in production, at scale, on the input you did not test.

The academics measured this. UC Berkeley's Sky Computing Lab built MAST, the Multi-Agent System Failure Taxonomy, by analyzing over 1,600 execution traces across 7 popular multi-agent frameworks. They found 14 distinct failure modes, and the breakdown is the part you should tattoo on the wall: 41.8% of failures came from specification and design issues, 36.9% from inter-agent misalignment, and 21.3% from verification failures.

Read that again. Almost 80% of the failures are design and agents talking past each other. Not the model being dumb. The model is fine. The system around it is where things break, and adding more agents adds more surface for exactly the two failure classes that already dominate. To make it concrete: ChatDev, a state-of-the-art open-source multi-agent coder, scored just 33.33% correctness on the MAST ProgramDev task. A team of agents pretending to be a software company got two out of three wrong.

Supervisor vs swarm, when you actually need more than one

Say you have earned it. The task is big, read-heavy, and one agent genuinely underperforms. Now the pattern choice matters, and it comes down to control flow.

The supervisor centralizes. Every request goes through one lead agent that picks workers and synthesizes their output. You get a single place to reason about state, log decisions, and enforce a single writer. This is the shape I default to, because it keeps the control flow legible. LangGraph ships a langgraph-supervisor helper that builds this topology in a few lines, which tells you it is the common production choice.

The swarmdecentralizes. There is no supervisor, agents hand off control directly to each other, and only one agent is active at a time. This shines for routing-style problems where the natural model is “this is really a refunds question, take it,” and you do not want a central bottleneck classifying every turn. LangGraph ships a separate langgraph-swarm package for it. The fact that both helpers exist as first-class tools tells you these two are the dominant productionized shapes in 2025 and 2026.

OpenAI walked this same road in public. It shipped Swarm as an experimental, educational framework in October 2024, built on two primitives, agents and handoffs. It caught on, hit roughly 21.8k GitHub stars, and then got retired. On March 11, 2025, OpenAI replaced it with the production-ready Agents SDK, keeping those same two primitives and adding guardrails, tracing, sessions, and TypeScript support. The evolution is the lesson: the toy taught the concept, and production needed guardrails and tracing, the unglamorous plumbing, more than it needed more agents.

The move that isn't more agents: skills

There is a quieter trend that I think is more important than any of these topologies. Late in 2025 Anthropic released Agent Skills, and in March 2026 opened the format as a shared cross-platform standard. The bet there is not more agents. It is reusable capability packaging: give one agent a library of well-defined skills it can load on demand, instead of standing up a new specialist agent for every capability.

That is the direction I would watch. A lot of what people build a second, third, and fourth agent to do is really just a capability the first agent could have if you packaged it well. One competent agent with a deep toolbox is easier to reason about, cheaper to run, and far easier to debug than a committee of narrow ones passing notes. Skills push complexity into libraries, where we already know how to manage it, instead of into runtime coordination, where we clearly do not.

So what do you actually build

My honest decision procedure, in order:

1. Try one optimized LLM call with retrieval. Ship it if it clears the bar. A surprising amount of the time it does.
2. If steps are fixed, use a pipeline. Draft then critique then rewrite is code, not a swarm. You get determinism and easy debugging for free.
3. If one agent underperforms on read-heavy, fan-out work, use a supervisor with a single writer. Spend the tokens on purpose, knowing the bill is real.
4. Reach for a swarm only when routing between specialists is the actual problem and a central classifier is a genuine bottleneck.
5. Reach for full autonomy last, and only where you can tolerate the failure modes MAST catalogued and afford to verify the output.

The whole field is biased toward the flashy end of that list because flashy demos well. The data points the other way. Token spend, not architecture cleverness, drives most of the measured gains. Most failures come from coordination, and coordination is the thing extra agents add. The simplest shape that ships is almost always the right one, and the burden of proof belongs to complexity, not to simplicity.