Eleven Multi-Agent Orchestration Patterns: A Technical Reference

Quick Navigation

Difficulty: Advanced
Estimated Time: 20-30 minutes
Prerequisites: LLM agent fundamentals, distributed systems basics, prompt engineering, agent tool use

The supervisor pattern, the de facto production standard at Klarna, Uber, and LinkedIn, benchmarks at 88% accuracy on simple tasks and 62% on complex ones. That 26-point degradation is the single most important data point in multi-agent design, because it quantifies what happens when you route all decision-making through one bottleneck and then hand it work that doesn't decompose cleanly.

Every pattern below is a different answer to the same three questions: how is control distributed, how does coordination overhead scale with agent count, and where on the latency-versus-quality curve does the topology sit. None of them is universal. The selection criteria are structural — they follow from the shape of the workload, not from preference.

What follows is one section per pattern: the topology, the operating envelope, and the failure mode. The table below is the at-a-glance version; the sections after it are the reasoning behind each row.

Supervisor

Topology: User -> Supervisor -> [A, B, C] -> Supervisor -> Response. A single central agent classifies the incoming task, dispatches subtasks to specialist workers, collects their outputs, and synthesizes the final response. Control is fully centralized; workers are stateless with respect to each other.

Operating envelope: 3–8 agents, medium latency. Quality is 88% on simple tasks, 62% on complex. Optimal when task decomposition is clear and specialist roles are well-defined.

Failure mode: The supervisor's context window is the hard ceiling on total system complexity, because every routing and synthesis decision passes through it. As task interdependence rises, the supervisor must hold more cross-worker state than it can reason about, which is exactly where the complex-task accuracy collapses. The pattern is legible and easy to debug — swap a specialist without touching the rest — but it does not scale past the single-coordinator limit.

Hierarchical

Topology: Top Supervisor -> [Team Lead A, Team Lead B] -> [A1,A2,A3] [B1,B2,B3]. Supervisors managing supervisors. Each level has visibility only into its own scope: the top coordinator reasons over team leads, team leads reason over their workers, and no node sees the full tree.

Operating envelope: 10–100+ agents, medium latency, good quality. The only topology in this set that scales to enterprise agent counts. Best for multiple domains and sector isolation, where each subtree can fail independently.

Failure mode: Scope isolation is the mechanism and the liability. Splitting decision load across team leads is what lets the system exceed the single-supervisor ceiling, but the top coordinator now acts on summaries that are several layers removed from ground truth. Latency accumulates through the layers, and a misaligned intermediate summary propagates upward without correction. You scale by hiding agents from each other — the cost is decision-making on abstracted state.

Sequential Pipeline

Topology: Agent A -> Agent B -> Agent C -> Agent D. A fixed linear chain. Each agent's output is the next agent's input. There are no routing decisions anywhere in the chain — the path is static and known at design time.

Operating envelope: 2–6 agents, slow (latency is the sum of all stages), fully predictable quality. Best for document processing, ETL, and content pipelines where step order is non-negotiable.

Failure mode: Total latency equals the sum of every stage because no execution overlaps — stage B cannot begin until stage A completes, even when no real dependency forces that ordering. The predictability is the payoff: behavior is completely reasoned-about because there is no branching. But if your stages are actually independent, the linear constraint is pure waste and you should be fanning out instead.

"A pipeline buys total predictability at the price of total serialization. Use it only when order is a requirement, not an accident."

Parallel Fan-Out/In

Topology: Router -> [A, B, C] (parallel) -> Aggregator. A router dispatches subtasks to multiple agents that execute simultaneously, and an aggregator merges their results. The defining property: wall-clock latency equals the slowest single agent, not the sum.

Operating envelope: 2–10 agents, fast, good quality. Best for independent subtasks and speed-critical queries where the work parallelizes cleanly.

Failure mode: The pattern assumes zero inter-agent dependencies. The instant one agent requires another's output, you have introduced an ordering constraint into a topology built on the absence of one, and the aggregator either blocks or merges incomplete state. Correct decomposition makes this the highest speed-to-effort ratio in the set; incorrect decomposition produces silently wrong aggregates.

Collaborative Debate

Topology: A writes -> B critiques -> A revises -> B approves. Agents review each other's output in an iterative refinement loop that continues until consensus. The critic's sole objective is to surface errors the author missed.

Operating envelope: 2–4 agents, slow (iterative), highest quality of any pattern here. Consumes significantly more LLM calls per query. Best for quality-critical decisions: legal, medical, compliance.

Failure mode: Cost and latency scale with the number of refinement rounds, which is data-dependent and not bounded in advance. This is the only topology that manufactures disagreement deliberately — every other pattern minimizes conflict, debate maximizes it to catch errors a single pass cannot. The trade is correctness for both speed and money, which is the right trade only when the cost of a wrong answer dominates the cost of compute.

"Debate treats disagreement as a feature. That is precisely why it is the wrong tool for any query where a single confident answer is good enough."

Swarm

Topology: [A1][A2][A3]...[A100] -> shared memory/bus. Hundreds of agents executing independently with minimal coordination, communicating only through shared state or a pub/sub channel. There is no coordinator and no negotiation.

Operating envelope: 10–1000 agents, fastest in the set, highly variable quality. Best for embarrassingly parallel workloads: batch analysis, large-scale scraping.

Failure mode: Removing coordination is what unlocks the agent count and the speed, and it is also why output quality is unpredictable per-agent. There is no mechanism to enforce consistency across the population, so the pattern is suited to volume, not precision. You deploy a swarm for scale and accept variance as the cost of having no central control.

Peer-to-Peer

Topology: A B, B C, C D, D A. No hierarchy. Agents communicate directly, negotiate, and reach consensus among themselves. There is no single point of failure because there is no central node.

Operating envelope: 3–10 agents, variable speed, variable quality. Best for distributed problems and multi-party negotiation, where no single agent should hold authority.

Failure mode: Emergent negotiation is inherently harder to predict than a fixed command structure, which is why both speed and quality carry the "variable" label. The absence of a single point of failure is a genuine resilience property, but it trades determinism for it — convergence time and output consistency depend on the negotiation dynamics rather than a controllable plan.

Note: Swarm and peer-to-peer both surrender central control, in opposite directions — swarm scales it away, peer-to-peer distributes it. Neither is appropriate when consistent output is a requirement.

Plan-and-Execute

Topology: Planner -> [Step1,2,3] -> Executor(s) -> Replan if failed. A planner generates the complete plan upfront. Executor agents — typically on a cheaper model — run each step. A replanner is triggered only on failure.

Operating envelope: 1+N agents (one planner, N executors), medium latency, good quality. Best for complex multi-step tasks and cost optimization.

Failure mode: The cost model is the entire point: expensive reasoning is paid for once at planning time, then steps execute on a budget model. The exposure is that the upfront plan is committed before execution reveals reality, so plan quality bounds the whole run, and frequent replanning erodes the cost advantage that justified the topology in the first place.

Reflexion

Topology: Execute -> Self-evaluate -> Feedback -> Retry improved (loop). A single agent with a self-reflection loop. It executes, evaluates its own output, feeds the critique back into the next attempt, and retries — maintaining a persistent memory of prior attempts to learn what not to repeat.

Operating envelope: 1 agent, slow (iterative), high quality. Best where quality outranks speed: code generation, content creation, reports.

Failure mode: Self-evaluation is bounded by the agent's own ability to detect its errors — there is no external critic, so blind spots persist across retries. The persistent failure memory is what differentiates it from naive retry, but iteration count is data-dependent and latency grows with it. It is the single-agent analogue of debate: same quality-over-speed trade, without a second perspective.

Router

Topology: User -> Classifier -> (pick ONE) -> AgA or AgB or AgC. A classifier selects the single best agent for each query and hands off. Only one agent ever processes a given request, so it is not truly multi-agent — it is dispatch.

Operating envelope: 1 agent per query, fast, good quality. Best for diverse query types where each class needs a different tool or specialist.

Failure mode: All system quality reduces to classifier accuracy. A misclassification routes the query to the wrong specialist with no recovery path, since no other agent participates. It is lightweight and the agents stay fully independent, but it provides none of the cross-checking, synthesis, or parallelism that the genuinely multi-agent topologies offer.

Conclusion: Compose, Don't Choose

The recommended architecture for a real large-scale system is not one pattern but four, composed: a supervisor at the top, hierarchical sector teams beneath it, parallel fan-out where latency is the constraint, and human-in-the-loop gates at the critical decision points. This is the operationally correct reading of the eleven patterns — they are a vocabulary, not a menu.

The selection logic is structural and reduces to matching topology to workload shape. Centralized control where the task decomposes cleanly (supervisor). Layered scope isolation where agent count exceeds the single-coordinator ceiling (hierarchical). Simultaneous execution where subtasks are independent (fan-out). Iterative cross-examination where a wrong answer is unacceptable (debate). Pick a single pattern for a system that contains regions with different requirements, and at least one region runs on the wrong topology by construction.

The diagnostic question for any deployment, then, is regional rather than global: for each subsystem, does correctness justify the per-query cost of debate, does scale demand the abstraction cost of hierarchy, and is any part of the system quietly running a supervisor against complex work at 62%?