Multi-agent orchestration patterns

A vocabulary, not a menu

Once a job outgrows one agent, the question stops being whether to split and becomes how the pieces coordinate. Five arrangements cover nearly everything running in production today, and each one is a different answer to a single question: who decides what happens next? In a pipeline, nobody does - the order is fixed. In orchestrator-workers, a lead agent does. In fan-out, the data does. In critique, a second opinion does. In routing, a classifier does, once, at the front door.

This article assumes the split itself is already justified - Multi-agent systems covers when it is and when one agent is still the right call. It also helps to hold on to the mechanical view from What's in an agent's context?: every agent below is one context window, and every pattern is really a policy for which window holds what, and what crosses between them.

One warning about names before the catalog. The industry has not settled its vocabulary: orchestrator-workers appears as "supervisor" or "lead agent," draft-and-critique as "evaluator-optimizer" or "reflection," routing as "triage" or "dispatch." The shapes are stable even where the labels are not, so match on the shape.

Orchestrator-workers

A lead agent holds the goal, breaks it into subtasks, hands each subtask to a specialized worker, reads what comes back, and decides what to do next - more delegation, a retry, or synthesis into the final answer.

The pattern earns its keep when the decomposition cannot be written down in advance - research is the canonical case, because what to look up next depends on what the last lookup returned. Each worker gets a clean window, a handful of tools, and instructions that do not have to compromise with anyone else's. The worker burns its own context on file reads and dead ends, then hands the lead a short artifact instead of the mess that produced it.

The costs are just as characteristic. The lead is a bottleneck and a single point of confusion: every result passes through its window, so a long run fills it exactly the way a single agent's fills, one level up. And delegation quality is instruction quality - a subtask phrased vaguely comes back as a confident answer to the wrong question, which the lead then synthesizes in without noticing. The reliable defence is to make every delegation carry three things: the original goal, the specific subtask, and the shape of the artifact expected back.

The sequential pipeline

A fixed chain of stages, each with one job and one defined artifact handed to the next: extract, then validate, then format. No coordinator, because there is nothing to coordinate - the order is the design.

With runAgent standing in for whatever your framework calls invoking one agent, the whole pattern is a page of ordinary code:

const brief = await runAgent("extractor", { source: reportUrl });

assertShape(brief, ["claims", "sources", "openQuestions"]);
// fail here, while the extractor is responsible -
// not two stages later, when nobody is

const checked = await runAgent("validator", { brief });
const memo = await runAgent("formatter", { checked, style: "exec-memo" });

This is the boring pattern, and it is right far more often than it is chosen. Whenever the steps are actually known in advance - which for extraction, review, formatting, and report-shaped work is most of the time - the pipeline is easier to debug than anything dynamic, because a bad output names its stage and the run can restart from the artifact before it. Teams routinely build an orchestrator for work that never deviates from the same three steps, then spend weeks debugging a coordinator that had nothing to decide.

Skip it when stages genuinely need each other's full working context, or when the path varies per input - forcing either case through a fixed chain means fat handoffs or a chain per case, and both are signs you want a different pattern.

Parallel fan-out, fan-in

Split the work into independent shards, run the same worker over each in parallel, and merge the results: one agent per file in a review, per region in an analysis, per document in a corpus.

The win is latency, and it is real: the run takes as long as the slowest shard instead of the sum of all of them. The price is paid twice. Once in tokens - every shard's window carries its own copy of the instructions and tool schemas, rent that a single sequential agent would pay once. And once at the merge, which is where the actual design work lives: deduplicating findings, resolving shards that disagree, and rewriting ten partial voices into one. A merge treated as concatenation produces a report that reads like ten people who never met.

The test for the pattern is independence. If shard three needs what shard one discovered, the shards are not shards - run them in parallel anyway and each quietly guesses at what the other knew. That dependency is the signal to fall back to a pipeline or an orchestrator.

Draft and critique

One agent produces the output; a second reviews it against explicit criteria; the first revises. Frameworks call it evaluator-optimizer, and its home ground is exactly where the user's stakes are highest: code review before a merge, analysis that ships to a client, any claim that will be acted on.

It works because generating and judging are different jobs that contaminate each other in one window. The drafter is committed to its own framing by the time it finishes; the critic arrives with a clean context, no attachment, and - this is the part that decides whether the pattern works - a rubric. "Find missing tests, unhandled errors, and claims without a source" produces findings. "Review this" produces compliments.

Two boundaries keep it honest. Cap the rounds, because the first round captures most of the value and an uncapped loop is two models politely disagreeing forever at your expense. And do not use a model where a mechanical check exists - linters, type checkers, and test suites are cheaper critics with zero false modesty, and the model critic should start where they stop.

Routing

A classifier sits at the front door, reads each incoming request, and dispatches it to the right specialist: billing questions to the billing agent, code tasks to the code agent, everything else to a generalist. Then it exits. That is the difference from an orchestrator - a router decides once and leaves, it does not supervise.

Routing pays off when the request mix is genuinely heterogeneous - support triage is the textbook case - because each lane gets a short prompt and a small tool set instead of one agent carrying every tool for every case. The router itself should be the cheapest thing that classifies reliably: a small model, or plain rules where the signal is obvious. Two design rules do most of the work: keep the lanes few and clearly separated, and always include a default lane, because the misfits will come and a router forced to choose between wrong lanes chooses one. Log the misroutes - they are your lane taxonomy's bug reports.

A close cousin is the handoff, where the agents themselves pass control mid-run instead of a classifier deciding up front - Multi-agent systems covers that shape and its tracing costs.

Combining patterns

Real systems compose. A router in front of three pipelines, one per lane. A pipeline whose final stage is a draft-and-critique gate. An orchestrator whose "worker" is itself a small pipeline. All of these are sound, and they share a property worth copying: each pattern is applied whole, at an artifact boundary, and the pattern in use at any point in the run is never ambiguous.

Hierarchy - an orchestrator whose workers orchestrate workers of their own - also exists, and it is the combination to be slowest to reach for. Every layer adds a boundary tax in tokens, a translation loss in the handoffs, and another level a trace has to cross before it explains anything. Very large jobs earn it; most jobs that reach for it wanted a flatter shape with better artifacts.

The anti-pattern is blending rather than composing: an orchestrator that sometimes lets workers hand off to each other directly, a pipeline with an undocumented shortcut lane. Nothing forbids it at build time, and no trace will explain it at debug time.

Choosing one

The mapping is more mechanical than the naming wars suggest:

• Steps known in advance → pipeline.
• Decomposition depends on what comes back → orchestrator-workers.
• Same task over independent shards → fan-out, fan-in.
• One output that has to be right → add a critique gate.
• Many kinds of request, one front door → routing.

Choose the least dynamic pattern that fits. Every decision you let the system make at run time is one you will eventually have to debug at run time.- the pipeline-first rule

If none of the five fits cleanly, the problem is usually the split, not the catalog - go back to the boundary test from Multi-agent systems and name the artifact that will cross each seam. And whichever pattern wins, it changes what you have to measure: per-agent pass rates that all look healthy can still compose into a system that fails, which is why evaluation has to run end to end, not per box. The frameworks in AI agent frameworks ship most of these shapes off the shelf - what they cannot ship is the decision about which one your job is.