Multi-Agent Orchestration Patterns
Multi-agent architectures are 2026's most over-prescribed pattern in enterprise AI. Walk into almost any agent program review and you'll find a diagram with five or six labeled boxes — "Planner," "Researcher," "Critic," "Executor," "Coordinator" — connected by arrows, presented as the obvious way to build something serious. Ask why there are five agents instead of one, and the honest answer, most of the time, is that it looked more sophisticated in the architecture review, or that a tutorial modeled it that way, or that "multi-agent" is what serious systems are supposed to look like this year.
None of that is a justification. It's fashion, and fashion is an expensive way to build software. Every additional agent in a pipeline adds a handoff, a handoff is a place where context gets lost or misinterpreted, and a place where context gets lost or misinterpreted is a new failure mode you now have to eval, monitor, and debug. The burden of proof runs the opposite direction from how most teams treat it: it is on adding an agent, not on keeping one.
A single well-harnessed agent — good context, tight tool contracts, a solid eval suite — is the default. You earn the right to add a second agent by demonstrating, with an eval, that the single-agent baseline fails in a specific way that a second agent specifically fixes. "It feels more robust" is not a demonstration.
The four legitimate justifications
There are exactly four reasons to split work across multiple agents that hold up under scrutiny. If your architecture doesn't map cleanly to one of these, it's decoration.
1. Parallelism
Some tasks decompose into genuinely independent subtasks that don't need each other's intermediate state. A marketing content-ops pipeline that needs a competitor scan, a brand-voice check, and a legal-claims check on the same draft can run all three simultaneously — none of them needs the others' output to do its job, and running them in sequence just adds latency for no benefit. Fan the work out to three agents, fan the results back in to a fourth (or to the orchestrating process) that reconciles them. The justification is measurable: wall-clock time drops roughly in proportion to how independent the subtasks are, and you can prove it by timing the sequential version against the parallel one.
The trap here is calling something "parallel" when the subtasks actually share state. If the legal-claims check needs to know what the brand-voice check changed, they aren't independent, and fanning them out produces a reconciliation problem — two agents that each silently assumed a version of the draft that no longer exists once the other one's edits land.
2. Context isolation
A deep, exploratory search — combing through a large policy corpus, or reading fifty related claims to find a pattern — burns a large context budget on intermediate noise: false leads, irrelevant matches, half-formed hypotheses. If that search runs inside your main agent's context window, all of that noise stays in context for the rest of the conversation, degrading everything that comes after it (this is the context-rot problem from lesson 4, applied across a multi-step task instead of within a single call).
Spinning up a subagent to do the deep search in its own, disposable context window and return only the distilled conclusion — "the governing precedent is X, found in these three documents" — keeps your main agent's context clean. The subagent's exploratory mess never has to leave its own sandbox. This is the single most common legitimate justification for a subagent call in tool-using agent frameworks, and it is justified by a concrete resource (context budget), not a vague notion of specialization.
3. Independent review
A reviewer agent that evaluates another agent's output, with fresh context and — ideally — a different underlying model, catches a different class of error than the generating agent re-checking its own work. This is the multi-agent pattern with the strongest justification in this course, because it maps directly to a principle established in lesson 13: independent review beats self-review. Different eyes, not more passes by the same eyes. A generator agent that re-reads its own output is checking whether the output matches its own reasoning, which is close to checking nothing — the same blind spots that produced the error are still in the room when it's reviewed.
4. Specialization
Genuinely different tools, permissions, or system doctrine per role justifies a role split. A read-only researcher agent that can query claims history and policy documents but cannot write to any system, paired with a write-permitted executor agent that can file an approved adjustment but has no need for broad read access to unrelated case files, is a real permission-boundary distinction — not a cosmetic one. The split earns its keep because it lets you grant narrower, more auditable permissions to each role than a single agent with the union of both permission sets would need. This is a guardrail benefit (lesson 10), not a capability benefit — the same model could technically do both jobs, but you don't want one credential able to both browse everything and write anything.
"Specialization" is the justification most often abused to rationalize an architecture chosen for other reasons. If your "specialist" agents differ only in the wording of their system prompts, and use identical tools with identical permissions, you have one agent with an unnecessarily fragmented conversation, not a specialized architecture. Ask whether the split changes what the agent is allowed to do, not just what it's told to focus on.
Pattern catalog
Five patterns cover the overwhelming majority of legitimate multi-agent designs in enterprise use. Each maps back to one or more of the four justifications above.
| Pattern | When | Cost profile | Failure mode |
|---|---|---|---|
| Orchestrator-workers | A controller decomposes a task into subtasks and dispatches them to worker agents, then assembles results | Orchestrator's context grows with every worker result reintegrated; cost scales with worker count | Orchestrator becomes a bottleneck or a silent single point of failure if it mis-assembles worker outputs |
| Pipeline | Sequential stages, each agent's output is the next one's input (extract → classify → draft → format) | Costs add linearly per stage; latency is the sum of all stages, not the max | Errors compound — a mistake at stage one is invisible until several stages downstream, if it's caught at all |
| Review pair | Generator produces output, an adversarial reviewer agent (fresh context, ideally different model) checks it against explicit criteria before it ships | Roughly doubles cost on the reviewed step, but only on that step — cheapest justified pattern per unit of risk reduced | Shared-blind-spot committee if the reviewer is the same model with the same training biases as the generator |
| Debate | Two or more agents argue opposing positions before a judge (agent or human) decides, used for genuinely ambiguous judgment calls | Expensive — multiple full generations plus a judging pass; rarely worth it outside high-stakes ambiguous decisions | Performative disagreement that doesn't surface real new information, just verbose restatement of the same position |
| Subagent-for-context-budget | Main agent delegates a deep search or exploration to a subagent that returns only a distilled conclusion | Net cost can be lower than doing the search in the main context, because the main agent's context stays small for the rest of the run | Subagent returns a confidently wrong summary and the main agent has no way to spot-check the discarded detail |
A utility's field-ops copilot uses exactly two of these patterns and nothing else. A subagent-for-context-budget pattern handles the "look up this transformer's maintenance history across fifteen years of scanned work orders" step, returning a three-sentence summary instead of dumping thousands of tokens of OCR'd text into the main conversation. A review pair checks every generated work order against a hard-coded safety checklist before it reaches a dispatcher, using a different, cheaper model than the generator specifically so it isn't inheriting the generator's blind spots. That's the whole multi-agent surface area. No planner agent, no coordinator agent, no five-box diagram — because nothing in the workflow demonstrated a need for one.
Subagents as backend jobs
Two of the patterns above — orchestrator-workers and subagent-for-context-budget — quietly imply a piece of machinery the box-and-arrow diagrams almost never show. A parent agent that dispatches work needs a small process manager: something to launch jobs, inspect their logs while they run, cancel the runs that have gone off the rails, and merge the surviving results back into its own context. Weng (2026) frames this as a backend-jobs pattern, and it is exactly what you want when you're searching several hypotheses in parallel — spin up a worker per hypothesis, let them run, keep the ones that panned out — or when you're delegating an isolated subtask specifically so its intermediate mess never touches the main conversation. The delegation tools that have standardized across coding agents (spawn, resume, wait, list, interrupt) are the concrete shape of this manager, not incidental conveniences.
The design principle that makes it work is worth stating on its own, because it is the difference between a subagent system you can operate and one you merely hope holds together: make the parallelism explicit and inspectable. If a subagent's output exists only in transient chat context, it goes obsolete the moment the run advances and becomes effectively invisible the moment anything interrupts the parent — you cannot resume what you cannot see. If instead each job's inputs, outputs, and status are written down as files, logs, and status records, two good things follow. The system can recover after an interruption by reading state back off disk instead of restarting from zero, and the model can reason over its own execution history — which jobs ran, which failed, what each one concluded — as ordinary retrievable context rather than as ephemera it has to hold in working memory. This is the filesystem-as-persistent-memory pattern from lesson 2 applied to orchestration: the same reason durable state belongs in files for a single agent is the reason a fleet of subagents should leave a paper trail rather than a chat log.
Parallelism you cannot inspect is parallelism you cannot recover or debug. Give the parent agent a real process manager — launch, inspect, cancel, merge — and persist each subagent's inputs, outputs, and status as files and logs, not as transient chat context. Durable orchestration state lets the system resume after an interruption and lets the model reason over its own run history instead of losing it the moment the conversation moves on.
Failure modes
Error compounding across handoffs. If each agent in a pipeline is individually 92% reliable on its step, and there's no independent check between steps, a four-stage pipeline's end-to-end reliability is not 92% — it degrades multiplicatively as errors pass through unexamined. A misclassified ticket at stage one produces a confidently wrong draft at stage three, and nothing in the pipeline is positioned to notice, because each stage trusts the previous stage's output by construction. This is the single strongest argument for keeping pipelines short and inserting a review step, not for avoiding pipelines altogether — but it means every extra hop has to earn its reliability cost, not just its capability benefit.
Shared-blind-spot committees. Five instances of the same model, prompted slightly differently and asked to "vote" or "reach consensus," is not a robustness technique — it's the same judgment, asked five times, dressed up as deliberation. If the underlying model has a systematic blind spot (a factual gap, a bias in how it interprets an ambiguous policy clause), all five instances share it, and the appearance of agreement actively hides the risk instead of surfacing it. Real independent review requires either a genuinely different model, a different context (so the reviewer isn't anchored on the generator's framing), or both.
Coordination overhead exceeding task value. An orchestrator that spends more tokens deciding which worker to dispatch to than the worker spends doing the actual work is a net loss dressed up as sophistication. This shows up most often when a task that a single well-prompted agent could complete in one pass gets decomposed into four sub-agent calls because the architecture template calls for decomposition, not because the task actually required it.
Cost blowup from redundant context. Every agent in a pipeline that needs to understand the original request typically gets a copy of the full context (the original ticket, the customer history, the policy documents) re-passed to it, because handoffs are rarely as clean as "just the conclusion." Multiply that by four or five agents and the token cost of a single task can be several times what a single-agent version would cost, for a reliability gain that a good eval might show is marginal or even negative once compounding is accounted for.
Run the numbers before you defend a multi-agent design on cost grounds. Teams often assume specialization or parallelism must be cheaper because each individual agent's job looks smaller. It frequently is not — redundant context passed to every hop, plus the review or reconciliation step needed to catch compounding errors, can make a four-agent pipeline cost more in tokens than one agent with a longer, well-structured single pass would have cost, for a comparable or worse reliability outcome.
Communication contracts
If you do add agents, the handoffs between them are now part of your system's interface surface, and they deserve the same rigor you'd apply to an API contract between two services — because that is exactly what they are.
Structured handoffs: schemas, not vibes. An agent handing off to another agent should pass a defined, validated structure — not a paragraph of prose the receiving agent has to re-interpret. If the researcher subagent's job is to report findings to the executor agent, define the shape:
{
"finding": "string, one sentence, the conclusion",
"confidence": "high | medium | low",
"supporting_refs": ["doc_id", "doc_id"],
"caveats": ["string", "..."],
"recommended_action": "string | null"
}This does two things a prose handoff doesn't. It forces the sending agent to actually resolve ambiguity into a confidence level instead of hedging in paragraph form, and it lets the receiving agent (or your monitoring) validate the handoff mechanically — a missing confidence field is a detectable, loggable error; a vague paragraph that quietly under-communicates uncertainty is not.
Explicit success criteria per hop. Each agent-to-agent handoff should have a stated definition of "this hop succeeded" independent of whether the overall task later succeeds. If the subagent's job is "find the governing precedent," success is "a precedent was found and cited with a source," not "the final ticket got resolved" — that outcome depends on steps the subagent doesn't control. Conflating hop-level success with end-to-end success makes it impossible to localize failures when the pipeline underperforms.
Log every inter-agent message for replay. When a multi-agent run produces a wrong answer, your ability to diagnose which hop introduced the error depends entirely on having the full message trail — what each agent received, what it returned, and the structured handoff in between. Treat this the same way you'd treat request/response logging between microservices: it is not optional instrumentation, it's the only way an incident review (lesson 14's improvement loop) can find where in a five-hop chain things actually went wrong instead of guessing.
Multi-agent handoffs are interfaces. Define them with schemas, give each hop its own success criterion, and log every message. An architecture with clean agent boundaries but sloppy handoff contracts will fail exactly like a microservice architecture with no API versioning and no request logging — mysteriously, and only in production.
The governing rule
Keep the smallest system that meets the eval bar. Add an agent only when a single-agent baseline has been run against your eval set and has demonstrably failed in a specific, identifiable way that a second agent specifically addresses — a context budget exceeded, a review step that catches errors the eval shows the generator misses on its own, a permission boundary that a single credential can't safely represent. And once you add the second agent, keep the single-agent baseline running as a control. If the multi-agent version's advantage on your eval set shrinks or disappears as the underlying model improves — which happens, because frontier models get better at exactly the long-horizon, multi-step tasks that used to require decomposition — you want to know that from your own eval data, not discover it eighteen months later when someone asks why you're running a five-agent pipeline that a single call now handles as well.
This week: take one multi-agent pipeline currently in production or design, and write down, for each agent in it, which of the four justifications (parallelism, context isolation, independent review, specialization) it satisfies. If an agent doesn't clearly satisfy one, build the single-agent version of that step and run both against your eval set. Keep whichever one clears the bar with less complexity — and if they tie, keep the single-agent version, because complexity has an ongoing maintenance cost the eval score doesn't capture.
Connecting back to review architecture
Of the four justifications and five patterns in this lesson, one deserves to be treated as close to a default rather than an exception: the review pair. Lesson 13 established that independent review beats self-review because it brings different eyes, not more passes by the same eyes, to catch errors a generator is structurally blind to in its own output. A second agent — fresh context, and ideally a different model than the generator — checking output against explicit criteria before it ships is the multi-agent pattern with the best cost-to-reliability ratio in this entire catalog, because it adds exactly one hop, doubles cost only on the reviewed step, and directly targets the failure mode (confidently wrong output passing unexamined) that harms production systems the most. If you take away one multi-agent pattern from this lesson to actually implement, it should be the one you already have half the justification for from four lessons ago: almost every serious pipeline should have an independent review pair, even when it has nothing else.
Key takeaways
- Multi-agent architecture is over-prescribed by fashion; the burden of proof is on adding an agent, not on keeping a single-agent baseline.
- Only four justifications hold up: parallelism (independent subtasks), context isolation (a subagent absorbs exploratory noise in its own context), independent review (different eyes, not more self-checks), and specialization (a real permission or tool boundary, not just a differently worded prompt).
- The pattern catalog — orchestrator-workers, pipeline, review pair, debate, subagent-for-context-budget — each has a distinct cost profile and a distinct failure mode; match the pattern to the justification, not to a template.
- Errors compound across handoffs, same-model committees share blind spots and only look like consensus, coordination overhead can exceed task value, and redundant context passed at every hop can make a multi-agent design more expensive than a single well-structured agent.
- Treat inter-agent handoffs as interfaces: structured schemas instead of prose, explicit per-hop success criteria, and full message logging for replay during incident review.
- The governing rule is to keep the smallest system that meets the eval bar, add an agent only when a single-agent baseline demonstrably fails on your eval set, and keep that baseline running as a control as models improve.
- A parent that dispatches subagents needs a real process manager (launch, inspect, cancel, merge); make the parallelism explicit and inspectable by persisting each job's inputs, outputs, and status as files and logs, so the system can recover after interruptions and the model can reason over its own execution history.
- The review pair — independent reviewer, fresh context, ideally a different model — is the one multi-agent pattern almost every serious pipeline should have, directly extending lesson 13's case against self-review.
Check your understanding
1. A team splits a single agent into a "Planner" and an "Executor" whose system prompts differ but which share identical tools and identical permissions. Which of the four legitimate justifications does this split satisfy?
2. Five instances of the same model are prompted with slightly different framings and asked to vote on an answer, which is presented as a robustness technique. What does the lesson say is wrong with this approach?
3. Why does the lesson recommend structured schemas for inter-agent handoffs instead of free-text prose summaries?
4. Per the lesson's governing rule, when is it justified to add a second agent to an existing single-agent system?