Multi-agent orchestration patterns: when one agent isn't enough

1. The question to ask before the architecture diagram

"Should this be multiple agents?" is almost always asked backwards -- as a design preference decided early, then justified later. The question that actually settles it is narrower: does this task have a natural seam where two different contexts, two different tool sets, or two different failure-recovery needs genuinely don't belong in the same reasoning loop? A single agent with a long system prompt and twelve tools can usually do more than its architecture diagram suggests, because the cost of adding "just one more tool" to an existing agent looks small in the moment, while the cost of adding a second agent looks large and deliberate up front. That asymmetry is backwards. A second agent is a second context window to manage, a second place state can drift, and a second component whose failure the first agent now has to detect and handle. It should be adopted because a real seam exists, not because the task feels big enough to deserve more than one agent.

The seam, when it's real, usually looks like one of three things: the sub-task needs a genuinely different tool authority level than the parent (a research step that only reads, feeding a deployment step that can write); the sub-task benefits from a context window that doesn't carry the parent's full history (a focused code-review pass that shouldn't be distracted by the forty-message planning conversation that preceded it); or the sub-task needs to run many times in parallel against independent inputs where a single agent would just be a slow loop wearing an agent costume. Absent one of those three, the second agent is probably decomposition for its own sake.

2. The four shapes, and what each one is actually for

Pipeline. Agent A's output is Agent B's input, in a fixed sequence -- research, then draft, then review. This is the shape to default to when the seam is about context isolation: each stage gets a clean context scoped to its own job, and the handoff between stages is an explicit, inspectable artifact rather than a shared, ever-growing transcript. Its failure mode is also its main cost: a pipeline is only as good as its handoffs, and a vague or lossy handoff (a summary that drops the one constraint stage two actually needed) produces a stage-two failure that looks like a stage-two problem but is actually a stage-one authoring problem.

Supervisor/worker. One agent plans and delegates; multiple worker agents execute narrow, bounded sub-tasks and report back. This is the shape for parallel, independent sub-tasks -- fan out ten file-level code reviews, fan them back in to one supervisor that synthesizes a verdict. The supervisor's job is explicitly not to redo the workers' reasoning; it's to decide what to delegate, judge what comes back, and resolve disagreements between workers. A supervisor that re-derives every worker's conclusion from scratch has turned an orchestration pattern into an expensive relay race.

Debate/critique. Two or more agents produce independent answers to the same question, then a judging step (a third agent, or one of the original two, or a human) reconciles them. This earns its cost specifically when a single agent's self-review is unreliable -- the same model grading its own homework tends to agree with itself, so an independent second pass, ideally with a different prompt or a different model, catches a different class of error than asking the first agent to "check your work" would. It's expensive in tokens for what it returns, which is why it belongs on high-stakes, low-frequency decisions, not on every step of a routine pipeline.

Swarm/market. Many agents work the same problem space with partial autonomy and loose central control, converging through local interaction rather than a central plan -- the shape behind some multi-agent research and simulation systems. It's the least common of the four in production software for a reason: it's the hardest to make predictable, the hardest to debug when it misbehaves, and the hardest to bound with a clear authority model. Reach for it only when the problem genuinely has no useful central decomposition, which is rarer than it sounds.

3. The cost side nobody puts on the architecture diagram

Multi-agent systems multiply three costs that single-agent systems only pay once: token cost (every agent re-establishes context, often re-reading material a different agent already read), latency (coordination overhead and sequential handoffs add wall-clock time that parallelism doesn't always buy back), and observability surface (a failure can now originate in any agent, in the handoff between any two agents, or in the orchestration logic itself, and the trace has to make clear which). None of these costs are hidden exactly -- they're just easy to underweight against the appeal of "the agents will handle it," which is a sentence that describes an architecture, not a guarantee.

Common mistake: treating "add a reviewer agent" as a free quality improvement. A second agent that reviews the first agent's output using the same model, the same base knowledge, and a system prompt that only says "be critical" tends to produce agreement dressed up as review -- real independent critique needs either a genuinely different vantage point (different tools, different context, a different model) or a concrete rubric the reviewer is checking against, not just an instruction to be skeptical.

4. A failure pattern worth naming: the vanishing error

A specific, recurring failure shape in multi-agent systems deserves its own name because it's easy to miss until it's expensive: an error in an early stage doesn't surface as an error, it surfaces as a plausible-looking downstream output built on a bad foundation. A research agent misreads a source; the drafting agent, working only from the research agent's summary, produces a fluent, well-structured piece built on the misread fact; a review agent, checking the draft for structure and tone rather than re-deriving the fact from the original source, approves it. Three agents, three successful-looking steps, one wrong artifact at the end -- and the trace shows every stage completing without error, because nothing actually errored. The only defense is making sure at least one stage in the chain re-verifies against the original source rather than trusting the prior stage's summary, which is a design decision, not something multi-agent architecture provides automatically.

5. A minimal checklist before adding agent number two

• A named seam. You can state, in one sentence, what context, authority, or parallelism boundary justifies a separate agent rather than a new tool or a longer prompt on the existing one.
• An inspectable handoff. Every boundary between agents produces an artifact a human can read and a test can check -- not an implicit trust that the next agent will correctly interpret the previous agent's intent.
• A traced origin for every output. Given a final result, you can identify which agent produced which part of it, without replaying the whole run.
• A plan for the vanishing error. At least one point in the chain re-checks against ground truth rather than trusting a summary of it.
• A cost estimate that includes coordination, not just inference. The token and latency cost of the handoffs themselves is counted, not treated as free because "the agents are doing the work."

6. Where this fits with the rest of the harness

Multi-agent orchestration is one discipline inside the broader harness a production agentic system needs -- see AI harness engineering for the full list, and context engineering for how to think about what each agent in a pipeline actually needs in its window versus what it's just inheriting out of habit. Eval-driven development matters more, not less, once a second agent is involved: an eval suite that only tests the final output can't tell you which stage actually broke, so a multi-agent pipeline needs evals at each handoff, not just at the end.