The three multi-agent patterns that actually work in production

Multi-agent systems are not a default choice. They're the right choice for specific problems: tasks too large for one context window, tasks that benefit from parallel specialization, tasks where independent verification improves accuracy. For everything else, a single capable agent is faster, cheaper, and easier to debug.

When you do need multiple agents, the architecture decision that matters most is the coordination pattern. Get this wrong and you've built a distributed system with all the coordination overhead and none of the reliability.

Pattern 1: Orchestrator-worker

Structure: One orchestrator agent decomposes the task and manages execution. Multiple worker agents execute specific subtasks. Workers report back to the orchestrator, which synthesizes results and decides next steps.

When to use it: Tasks with multiple independent subtasks that can be parallelized. Tasks too long for a single context window that can be decomposed into bounded chunks. Tasks requiring different specializations (a researcher worker, a writer worker, a reviewer worker).

What to get right:

The orchestrator is responsible for task decomposition, worker dispatch, result collection, and synthesis. It should not do substantive work itself — it should delegate. The orchestrator's context is a control plane: it tracks what workers were given and what they returned, not the full content of their work.

Workers should be stateless from the orchestrator's perspective. Each worker receives a bounded task with all the context it needs and returns a structured result. Workers don't share state with each other — they share it through the orchestrator.

The orchestrator should validate worker outputs before accepting them. A worker that returned an error, an empty result, or a structurally invalid response should trigger a retry or an escalation, not a silent failure that propagates to synthesis.

Failure modes to design for:

• Worker timeout: orchestrator should retry with a fresh worker, not wait indefinitely
• Partial worker failure: decide whether to synthesize with partial results or require all workers to complete
• Orchestrator context overflow: workers should return compact summaries, not full work products

Pattern 2: Pipeline

Structure: Agents in a fixed sequence. Agent 1 produces output. Agent 2 receives that output and produces its own. Agent N receives the cumulative result. Each agent has a single, bounded role.

When to use it: Tasks with a natural sequential structure where each step transforms the output of the previous one. Document processing (extract → classify → summarize → route). Analysis pipelines (gather → clean → analyze → report).

What to get right:

Each stage in the pipeline should have a defined input schema and output schema. These schemas are contracts. Stage 2 is built against the output schema of stage 1. When stage 1's output changes, stage 2's contract breaks.

Implement schema validation at each stage boundary. When stage 1 produces output, validate it against stage 2's input schema before passing it forward. Fail fast with a clear error rather than letting a malformed output propagate through three more stages.

Include a retry policy per stage, not just at the pipeline level. A transient failure at stage 3 shouldn't restart from stage 1. Checkpoint completed stages so recovery restarts from the failure point.

Failure modes to design for:

• Garbage amplification: a bad output at stage 2 propagates and degrades through stages 3, 4, 5. Validate at each boundary.
• Context bleed: early stages include content that's irrelevant to later stages, consuming context budget unnecessarily. Each stage should strip irrelevant content from its output.

Pattern 3: Peer debate

Structure: Two or more agents independently work on the same task and produce competing outputs. A judge agent (or a deterministic evaluation function) selects the best output or synthesizes the best elements of each.

When to use it: Tasks where accuracy is critical and errors are costly. Tasks where the model tends to be confidently wrong. Fact verification. Legal or financial document review. Any context where you need independent verification, not just speed.

What to get right:

The debate is only as good as the independence of the agents. If both agents share the same system prompt, the same examples, and the same context, they'll tend to produce the same errors. Introduce variation: different system prompts, different retrieval strategies, different models where budget allows.

The judge should evaluate on explicit criteria, not just "which is better." Define what correctness, completeness, and accuracy mean for this task. The judge's evaluation prompt should include the criteria and ask for structured scoring, not a free-form pick.

Peer debate is expensive: two or three agent calls where one would do. Reserve it for high-stakes outputs where the cost of a wrong answer exceeds the cost of redundant computation.

Failure modes to design for:

• Judge bias: the judge has its own model and its own biases. It may consistently prefer outputs from agent 1 regardless of quality. Monitor judge decisions for systematic preference.
• Both agents wrong in the same way: common for systematic biases or systematic knowledge gaps. Peer debate doesn't correct for biases shared by all agents.

Choosing the right pattern

One practical test: can you draw the data flow as a DAG? If yes, orchestrator-worker or pipeline fits. If the task is monolithic but you need quality assurance, peer debate. If you can't draw a clear data flow, you probably don't need multiple agents — you need a better single agent.

The multi-agent system that works in production is the one where failures are attributable, retries are bounded, and each agent's responsibility is clear enough that you can test it independently. Build the coordination scaffold before you add the agents.