Multi-Agent Orchestration Patterns

Reading time ~19 min · Last reviewed Sep 2026 · Quiz at the end

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.

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 5, 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 20: 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 13), 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.

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.

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.

Teams: shared task boards and mailboxes

Every pattern so far has a hub. An orchestrator dispatches, a parent spawns a subagent, a generator hands off to a reviewer. A newer shape drops the hub, or shrinks it: several long-lived agents work the same codebase in parallel and coordinate through shared state (a task board, a mailbox, a repository) instead of through a controller that routes every message. It is the pattern most people mean now when they say "agent teams," and it is worth understanding precisely, because its coordination mechanism is boring on purpose.

A team with no manager: the C compiler experiment

Anthropic's "Building a C compiler with a team of parallel Claudes" (2026) is the clearest public account. Sixteen agents ran at once, each in its own Docker container with its own clone of a shared git repository. There was no orchestration agent; each agent decided for itself what to work on, usually picking the next most obvious problem. Coordination came down to three mechanisms:

• Lock files as a task board. An agent claimed a task by writing a lock file into a current_tasks/ directory. Because the claim went through git, two agents grabbing the same task collided at push time, and the second had to pick something else.
• Git as the message bus. Finishing a task meant pulling upstream, merging the other agents' changes, pushing, and removing the lock. Merge conflicts were frequent, and the agents resolved them themselves.
• Tests as the shared definition of done. The post puts heavy weight on high-quality tests, including GCC as a known-good oracle to compare outputs against. When agents stalled on compiling the Linux kernel, the harness compiled random subsets of files with GCC and the rest with the new compiler, which split one giant failure into many independent ones that could be worked in parallel.

The result was a Rust compiler of about 100,000 lines that builds Linux 6.9 on x86, ARM, and RISC-V, from roughly 2,000 Claude Code sessions over two weeks at about $20,000. The post is candid about its limits, including generated code less efficient than GCC's with optimizations disabled. The lesson for harness engineers is less about compilers than about where the coordination lived. It lived in durable, inspectable artifacts (the repo, the lock files, the test suite), which is the "make parallelism explicit and inspectable" principle from the previous section applied without a parent at all. And the test oracle is what made independent work possible: parallelism existed only where the tests could split the problem into pieces that didn't share state.

Teams as a harness feature

Harnesses are starting to ship this shape as a component. DeepSeek Harness includes an experimental Agent Team package (DeepSeek, 2026) in which the session's agent becomes a Lead that creates named teammates, exchanges durable messages with them, and tracks work on a shared task board. The roster shows each member's status; an offline teammate's messages queue until it resumes, and the README says messages are never lost and never delivered twice. Only the Lead can create or interrupt teammates, and the configuration caps team size, active tasks, queued messages per member, and message size. The README is just as clear about what it does not do: teammates share one working directory, one process owns the team, and a task's owner is not released automatically. It carries no stability promise. Even so, the design choices are the ones this lesson argues for: durable state over chat context, explicit limits, and one agent with authority over the roster.

The same harness shows a second trend: a subagent does not have to be your own agent. DeepSeek Harness's subagent family (DeepSeek, 2026) offers a fresh in-process child, a child forked from the parent's history, or an out-of-process child backed by ACP, Codex (through its app-server protocol), Claude Code (through the Agent SDK), or another Harness runtime. Delegating a turn to a different product is a genuine specialization split in this lesson's sense, since the child brings its own tools, permissions, and possibly a different model. That makes it a candidate for independent review. It also means the handoff crosses a product boundary, so the structured-handoff and logging rules below matter even more: you are now debugging across two harnesses' logs.

Across organizations: A2A

When the agents on either end of a handoff belong to different organizations or vendors, the handoff contract needs to be a protocol. Agent2Agent (A2A) is the main candidate. The A2A project announced its first stable release, v1.0 (March 2026), and in August 2026 A2A joined the Agentic AI Foundation (2026), the Linux Foundation-directed body that also hosts MCP. The division of labor is roughly this: MCP connects an agent to tools and data, and A2A connects an agent to another agent it doesn't control. Everything this lesson says about handoffs still applies. A protocol gives you a common wire format and discovery; it does not give you per-hop success criteria, confidence fields, or a reason to add the second agent in the first place.

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.

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 21's improvement loop) can find where in a five-hop chain things actually went wrong instead of guessing.

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.

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 20 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.