Multi-Agent Orchestration: Five Patterns That Hold Up in Production

Once a system has more than one agent, something has to decide who runs next. That something is the orchestrator. The most common mistake I see is making the orchestrator another language model, a manager agent that reads everything and decides everything. It is slow, expensive and hard to debug. In most systems the orchestrator should be plain code, with models only inside the steps.

Pattern 1: Fixed pipeline

Agents run in a set order, each consuming the previous agent's structured output. Intake, then research, then draft, then check. Use it when the steps are known in advance, which is most business processes. It is the cheapest and easiest pattern to debug, because every run takes the same path.

Pattern 2: Router to specialists

A cheap classifier reads the request and hands it to one specialist agent. Each specialist has a short prompt and its own tools. Use it when requests come in distinct types, such as support, billing and sales. The router can often be a small model or even keyword rules.

Pattern 3: Planner with parallel workers

A planning agent splits a large task into independent subtasks, each with a short spec. Workers run in parallel, each with a fresh context holding only its spec. The planner receives short results and combines them. Use it for research, auditing many items, or generating many variations. Anthropic describes this orchestrator-worker shape in its multi-agent research system, and also notes it uses far more tokens than a single agent, so it must be worth it.

Pattern 4: Generator with checker

One agent produces, then checks run on the output. Code checks run first because they are free: schema, length, required fields, banned claims. A model reviewer runs only on what code cannot judge. If a check fails, the generator gets the specific error and one more try. Cap the retries.

Pattern 5: Human approval gate

Before an irreversible action, such as sending an email to a customer or writing to a production CRM, the orchestrator pauses and asks a person. The agent's output waits as a draft. This is the cheapest way to deploy agents into processes where a mistake is expensive.

Orchestration rules that save money

• Pass briefs, not transcripts. Each agent gets a schema-defined input, never the full history of the agents before it.
• Bound everything. Maximum steps, maximum retries, maximum spend per run.
• Log per agent. Tokens, cost, latency and check results per step, so you can see which agent to shrink.
• Make steps resumable. Store each step's output so a failure at step four does not rerun steps one to three.

Combining patterns

Real systems mix them. A content system I run is a fixed pipeline whose research step is a planner with parallel workers and whose writing step is a generator with a checker. The orchestrator is a few hundred lines of code. The intelligence is in the agents and the design is in the handoffs, which is the subject of agentic AI system design.

A worked example: a content pipeline

The content engine on my systems page combines three of these patterns:

1. Fixed pipeline as the outer shape: research, choose angles, write, check, approve, publish.
2. Planner with parallel workers inside research: one planner lists the questions, several workers research them at once, each returning a short summary.
3. Generator with checker inside writing: the writer drafts, code checks length, headings and banned phrases, and a reviewer scores against a rubric.
4. Human approval gate before publishing.

The orchestrator is code. It stores each step's output, so a failed writing step reruns writing only, not research.

Choosing a pattern

What to log in an orchestrator

• A run ID that links every step.
• Each step's input object, output object and check results.
• Tokens and cost per step and per run.
• Which pattern branch was taken, such as which specialist the router chose.

With that log, you can replay any run and see exactly where it went wrong. It is the same discipline I use in CRM workflow automation, applied to agents.

Claude and multi-agent orchestration

Coding tools and agent SDKs now ship with built-in support for sub-agents, where a main agent hands a focused task to a helper that starts with a clean context and returns a summary. That is the planner-with-workers pattern packaged for everyday use. The same rules apply: give the sub-agent a precise brief, keep its tools narrow, and take back a short result rather than its whole trace.

Failure handling per pattern

Frequently asked questions

What is multi-agent orchestration?

Multi-agent orchestration is the coordination of several AI agents: deciding which agent runs when, what input it receives, how outputs are combined or checked, and how failures are handled. It is usually implemented as code that calls agents as steps.

Should the orchestrator be an AI agent?

Usually not. A code orchestrator is cheaper, faster and easier to debug. A model-based orchestrator makes sense only when the order of steps genuinely cannot be known in advance, and even then it should receive short summaries, not full transcripts.

What are common multi-agent orchestration patterns?

A fixed pipeline, a router to specialist agents, a planner with parallel workers, a generator with a checker, and a human approval gate. Most production systems combine two or three of these.

What is AI agent orchestration?

AI agent orchestration is the coordination layer that runs AI agents in the right order or in parallel, passes structured results between them, enforces limits and checks, and handles retries and human approvals.

How do you debug a multi-agent system?

Give every run an ID, store each step's input and output objects with check results, and log tokens and cost per step. Then replay the failing run and find the first step whose output was wrong.

What is a sub-agent?

A sub-agent is a helper agent started by a main agent to handle a focused task with its own clean context and tools. It returns a short result, which keeps the main agent's context small.