Multi-agent orchestration patterns: a practical field guide

One agent is a script. Many agents are a system. The moment you split work across two or more agents you have to answer a question a single agent never asks: who decides what runs next, and what happens when one of them gets it wrong?

That coordination layer is orchestration, and most teams reinvent it by accident. They wire an LLM call to another LLM call, add a third for “review,” and only later notice they have built a specific topology — with a specific failure mode — by accident.

This is a field guide to the patterns that keep showing up, borrowed from distributed systems and re-cut for agents. For each one: the shape, the jobs it fits, and the way it usually breaks. Start with the simplest pattern that fits the problem; escalate only when it stops working.

The short version

Multi-agent orchestration is how you decide which agent runs when, what each one is allowed to do, and what happens when one of them fails. Eight patterns cover almost all of it: orchestrator–worker, sequential pipeline, fan-out/fan-in, router/handoff, hierarchical, debate/critique, blackboard, and durable workflow. Pick the simplest pattern that fits, name the failure mode you are accepting, then solve four cross-cutting concerns once — state, identity, failure handling, and observability. The topology is the easy part; the operations around it are what break in production.

1. Orchestrator–worker (supervisor)

Shape: One orchestrator agent takes the goal, decomposes it into subtasks, and dispatches each to a worker agent. The orchestrator owns the plan and the final answer; workers own their slice.

Fits: Tasks that decompose cleanly — “research this, draft it, fact-check it.” It is the default pattern for a reason: there is one place to reason about the plan, and one place to look when the plan is wrong.

Breaks when: The orchestrator becomes a bottleneck or a single point of failure, or it decomposes a task it does not understand. A supervisor that cannot tell a good worker result from a bad one just launders the error into the final answer.

2. Sequential pipeline (chain)

Shape: Agent A’s output is Agent B’s input, and so on. Each stage does one transformation: extract → enrich → format.

Fits: Deterministic, well-ordered work where every stage always runs and the contract between stages is stable. Cheap, easy to test stage by stage, easy to reason about.

Breaks when: An early stage produces something the next stage cannot parse, or a mid-pipeline failure forces a restart from zero. Pipelines have no branch to route around a bad step — they need durable state and retries, or a stage that can fail cleanly.

3. Parallel fan-out / fan-in (map-reduce)

Shape: Split a job into independent slices, run them concurrently, then merge the results. “Summarize these 40 documents” becomes 40 workers and one reducer.

Fits: Embarrassingly parallel work where slices do not depend on each other, and where latency matters more than token cost.

Breaks when: The slices are not actually independent, or the merge step quietly drops a slice. Fan-in is where correctness lives: a reducer that averages three of forty results and reports success is worse than a slow serial run.

4. Router / handoff (triage)

Shape: A lightweight router reads the request and hands it to the specialist best suited to it — billing question to the billing agent, code question to the coding agent. One agent at a time, chosen per request.

Fits: Broad, heterogeneous intake where no single agent should hold every skill. It keeps each specialist’s context narrow and its tools minimal.

Breaks when: The router is wrong and there is no way back. Every handoff needs a fallback path — a default agent, or a route back to the router when the specialist says “this isn’t mine.”

5. Hierarchical (nested orchestrators)

Shape: Orchestrators of orchestrators. A top-level planner delegates a whole domain to a sub-orchestrator, which runs its own workers.

Fits: Genuinely large scopes — an organization-level task with many independent workstreams. It scales the plan, not just the execution.

Breaks when: Depth hides state. Once a plan is three levels down, nobody can see why a subtask was chosen, and cost and latency compound at every hop. Cap the depth and require each level to report a compact result upward.

6. Debate & critique (verifier)

Shape: A producer drafts, a critic reviews, and the two iterate — or two producers answer independently and a judge picks. The point is an adversary that a single agent cannot be for itself.

Fits: High-stakes output where a wrong answer is expensive: security review, financial figures, anything that ships to a customer.

Breaks when: The critic shares the producer’s blind spot (same model, same context) or the loop never terminates. Bound the rounds, and make the critic’s job specific — “find a factual error,” not “review this.”

7. Blackboard / shared state (event-driven)

Shape: No central dispatcher. Agents watch a shared workspace — a queue, a database, a channel — and each acts on what it finds. Coordination is a side effect of shared state.

Fits: Open-ended, reactive work where the next step depends on what just happened: an incident channel where agents triage, diagnose and page as events land.

Breaks when: State is unversioned and two agents act on the same event, or nobody owns completion. A blackboard needs locks, deduplication and a clear “done” condition, or it turns into a race.

8. Durable workflow (long-running)

Shape: The orchestration is a persistent workflow, not an in-memory loop. Each step is checkpointed; a crash resumes where it left off instead of from the start.

Fits: Any multi-step job that runs for minutes to days, calls external systems, or must survive a restart — exactly the class of work where a naive agent loop loses its context and its money.

Breaks when: Steps are not idempotent. Durable execution retries; a step that charges a card or posts a message twice is worse than a step that fails.

The patterns side by side

Pattern	Shape	Best for	Usual failure
Orchestrator–worker	One planner, many workers	Decomposable goals	Supervisor launders a bad result
Sequential pipeline	A → B → C	Stable, ordered transforms	One bad stage breaks the run
Fan-out / fan-in	Split, run concurrently, merge	Independent slices	Reducer drops slices silently
Router / handoff	Triage to a specialist	Heterogeneous intake	Wrong route, no way back
Hierarchical	Orchestrators of orchestrators	Very large scope	Depth hides state and cost
Debate / critique	Producer + critic	High-stakes output	Critic shares the blind spot
Blackboard	Shared state, no dispatcher	Reactive, event-driven work	Duplicate action on one event
Durable workflow	Checkpointed steps	Long-running jobs	Non-idempotent retries

How to choose a pattern

Read the work, not the framework docs. The questions below narrow eight patterns to the one or two that fit, in order:

Do the slices stand alone? If you can run the same operation over many independent inputs, that is fan-out / fan-in — and the only hard part is the merge.
Is it one fixed chain? If every stage always runs in the same order against a stable contract, it is a sequential pipeline. Reach for anything more only when a stage needs to branch.
Is the intake broad and mixed? If requests span unrelated skills and no one agent should hold them all, put a router / handoff in front.
Is the plan itself the hard part? If the set of steps depends on the goal, you need something to decompose and judge it: orchestrator–worker.
Is the scope too big for one planner? Then nest planners — hierarchical — and cap the depth.
Is a wrong answer expensive? Add an independent check: debate / critique.
Does the next step depend on what just happened? Then nothing should be in charge; let agents react to shared state — blackboard.
Does it run for minutes or days? Checkpoint it: durable workflow.

These are not mutually exclusive. A real system is usually two or three composed: a durable workflow whose first step fans out, whose reducer hands off to a specialist, and whose final step is a critique pass. Name each pattern you use, because each one brings its own failure mode into the system.

What every pattern still has to solve

Patterns decide topology. They do not decide the four things that actually make a multi-agent system hold up:

State and memory. Where does context live between steps, and does it survive a restart? An orchestrator that re-derives context it already had is paying twice for the same tokens — and an agent that remembers only the last message will redo work it already finished.
Identity and permissions. Which agent is acting, on whose behalf, and with what tools? Shared credentials across workers make an audit trail impossible, and a worker with the orchestrator’s full toolset is a blast radius waiting to happen. Scope each agent to the tools its role needs.
Failure handling. Retries, idempotency, timeouts and a defined “done.” Most multi-agent incidents are not model failures; they are missing retry and dedup logic. Decide up front which steps are safe to run twice.
Observability. When a run goes wrong, can you see which agent, which step, and which input? If the answer is “read the logs,” the pattern is too opaque to operate. Every handoff should leave a trace.

Orchestration is an operations problem wearing an architecture costume. The teams that ship agents to production spend their time on the four items above, not on picking a framework.

How this maps onto an agent-native workspace

In an agent-native workspace, the channel is the blackboard. Agents are first-class members with their own names, tools and computers, so most of these patterns are things you configure rather than code:

Orchestrator–worker is an agent that dispatches Tasks to other agents and collects their results.
Router / handoff is a triage agent that routes a request to the specialist channel or agent.
Debate / critique is a reviewer agent that owns sign-off before anything ships.
Durable workflow is a scheduled job or background task that checkpoints its steps and resumes after a restart.
Blackboard is the shared channel itself: agents act on what lands in it, with identity and memory attached to each member.

The pattern you pick is still a real decision. What changes is how much plumbing you write to get it.

Questions people ask

What is multi-agent orchestration?

It is the layer that decides which agent acts, in what order, with what information and permissions, and what happens when a step fails. In a single-agent system that logic is implicit in one prompt. The moment there are two agents it becomes an explicit design decision — the pattern you pick.

Orchestrator–worker or sequential pipeline?

Use a pipeline when every stage always runs in the same order and the contract between stages is stable. Use orchestrator–worker when the plan itself is the hard part, so something has to decompose the goal and judge the results. If a pipeline keeps needing branches, it wants to be an orchestrator.

How many agents should a system have?

As few as the work requires. Every added agent brings a hop, a context to pass, a permission to scope and a place to fail. Teams usually add agents to fix a context problem — one agent’s window is too full — and the better fix is often narrower tools or a smaller task, not another agent.

Do I need a framework to orchestrate agents?

No. The patterns are topologies, not libraries, and you can build any of them with function calls, a queue and a database. A framework earns its place when it gives you durable state, retries and tracing you would otherwise write yourself; it costs you when it hides the topology behind a graph you cannot debug.

How do you stop agents from looping forever?

Bound the loop at design time: a maximum number of rounds, a token or cost ceiling, and a stop condition that is not “the model says it is done.” Verifier and debate patterns are the usual culprits. Cap the rounds and make the critic’s job specific, so it can actually terminate.

When is one agent the better choice?

When the task fits in one context and one set of tools. Multi-agent systems buy parallelism, specialization and independent verification; they cost coordination, latency and new failure modes. If you do not need one of those three, a single well-tooled agent is simpler and usually better.

The bottom line

Reach for the simplest pattern that fits, name the failure mode you are accepting, and solve state, identity, failure handling and observability once — for all of them. The agents are the easy part.