Multi-agent orchestration is the coordination of multiple AI agents — separate model calls with distinct roles, prompts, or tools — so that their combined output completes a task more reliably than any single call. The orchestration layer decides which agents run, in what order, and how their disagreements are resolved. That last clause is the part vendor pages skip and the part that can be measured: resolution, not agent count, is where multi-agent systems are won or lost. This guide covers the four coordination patterns in production use, the aggregation pitfall we measured across six architectures, and the specific conditions under which a panel of agents beats one well-orchestrated model.
Disclosure up front: we build a managed mixture endpoint (Moamao) and publish our benchmark methodology, replications, and retractions in full. Every number below is scoped to our frozen benchmark suite — treat it as evidence about mechanism, not a universal ranking.
The four coordination patterns
Nearly every multi-agent system in production reduces to one of four shapes, used alone or nested inside each other.
Supervisor/worker.A coordinator model decomposes the task, delegates subtasks to worker agents, and integrates their results. It fits work that genuinely decomposes — research-and-summarize, multi-file code changes — and it fails at the top: the supervisor’s plan and its final integration are single points of failure, invisible to workers who each did their piece correctly.
Pipeline.Agents run in a fixed sequence — extract, then draft, then edit — each consuming the previous stage’s output. Pipelines are predictable and easy to debug, but they compound errors: a mistake in stage one becomes the ground truth of every later stage, and nothing downstream is positioned to notice.
Debate.Agents answer independently, see one another’s answers, and revise over rounds. The bet is that critique surfaces errors. Sometimes it does; the characteristic failure is consensus drift — agents converging on a confident, fluent, wrong answer — while cost and latency multiply with every round.
Ensemble and aggregate. The same task goes to several agents in parallel, and a merge step produces one answer. This is the shape of the mixture-of-agents architecture, and of the Self-MoA result, which found that aggregating repeated samples from one strong model often outperforms mixing several different ones. Everything hinges on the merge step — which is where our own measurements come in.
| Pattern | Use when | Characteristic failure |
|---|---|---|
| Supervisor/worker | The task decomposes into independent subtasks | Plan and integration errors at the top propagate everywhere |
| Pipeline | Stages are stable and their order is known in advance | Errors compound downstream with no recovery path |
| Debate | Critique reliably surfaces errors and the budget is loose | Consensus drift; cost multiplies with every round |
| Ensemble + aggregate | Failures across agents are decorrelated | The aggregator becomes the new single point of failure |
The measured pitfall: letting a model judge the candidates
The ensemble pattern has a step most write-ups treat as a detail: something must pick or merge the candidates. The common choice is a judge model. We measured what that choice costs.
In our published research season, six mixture architectures — each with the correct answer provably present in its candidate pool — all scored at or below their own best member when a small model did the judging. The pool held the right answer; the judge lost it. We call this the selection bottleneck, and it puts a hard ceiling on judged ensembles: the best member’s score on a good day, lower on most days. The full data, hash-locked benchmark files, and pre-registered predictions are on the research page, along with the three same-day retractions we published when early framings did not hold.
A second measured effect makes judging worse than it looks: instruction-presence poisoning. Auxiliary instructions anywhere in a prompt — including the scaffolding an orchestrator injects — degrade knife-edge and sequential answers. Aggregation prompts are made of auxiliary instructions.
The design that survived our measurements is judge-free: two candidate pools merged by a single bit — did deterministic code substitute a computed value, yes or no. No model ever compares answers. It is the same instinct behind program-aided approaches like PAL: move the fragile step out of free-form generation and into something checkable.
When multi-agent beats a single model — and when it does not
Two conditions, both required. First, decorrelated failures: the agents must be wrong in different places, whether through different models, sampling temperatures, or prompt framings. Second, a merge that cannot subtract: deterministic verification, execution checks, or a one-bit rule — not a model’s opinion. Diversity without a safe merge feeds the selection bottleneck; a safe merge without diversity has nothing to gain.
When either condition fails, the panel is overhead. On our frozen benchmark suite, a single well-orchestrated 8B matched a two-model panel at 4.6× the speed — the second model’s cost bought no measured accuracy on that suite. The run-by-run data is in one model vs a panel.
The same architecture runs behind our API: one call executes a dual-pool mixture server-side, on hardware we own — a single consumer 8GB GPU with a qwen3:8b base. On our frozen ten-task tier-1 reasoning/context/memory suite it scores 10/10, replicated eight consecutive times, at roughly ten seconds per task; claude-opus-5 scores 10/10 on the same suite under the same harness. Across all our frozen suites the composite is 14.75/17 (87%) against Opus’s 17/17 — a measured gap we publish rather than round away.
FAQ
Is multi-agent orchestration the same as mixture-of-agents? No. Mixture-of-agents (MoA) is one pattern within multi-agent orchestration: parallel proposers plus an aggregation step. Multi-agent orchestration is the broader discipline, covering supervisor/worker, pipeline, debate, and ensemble-plus-aggregate designs. A plain-language walkthrough is in what is mixture-of-agents.
Does adding more agents make a system more accurate? Not by itself. In our published measurements, six judge-aggregated mixture architectures scored at or below their own best member even though the correct answer was provably present in the candidate pool. Accuracy gains require decorrelated failures across agents plus a merge step that cannot discard a correct candidate.
When should a single model be used instead of a multi-agent panel? When failures across the candidate agents are correlated, or when the latency budget is tight. On our frozen benchmark suite, a single well-orchestrated 8B model matched a two-model panel at 4.6× the speed.
What does multi-agent orchestration cost to run? Whatever multiplies model calls multiplies cost: a three-agent debate over two rounds is six or more calls per task, so per-task pricing matters more than per-token pricing. Our plans are flat: Free at $0 with a quota, Scale at $20/month, Max at $79/month, and BYOK unmetered — a full mixture run counts as one unit.
Related: the complete orchestration guide · multi-agent orchestration platforms compared · what is mixture-of-agents · the BYOK cost math