Mixture of Experts (MoE) is a neural-network architecture that routes each token to a small subset of specialized sub-networks inside a single model — a design decision made at training time by the model’s builder. Mixture of Agents (MoA) is an inference-time technique that sends one prompt to multiple complete models and aggregates their answers into one. The two terms share a word, an acronym shape, and the same pitch — specialists beat a generalist. They otherwise describe different layers of the stack, controlled by different people, with different cost profiles. Conflating them leads to concrete planning errors: budgeting for one while actually buying the other.
Mixture of Experts: routing inside one model
A dense transformer runs every parameter for every token. MoE changes that. It replaces some of the feed-forward blocks with a bank of parallel sub-networks — the “experts” — plus a small learned router (a gating network) that selects the top few experts for each token as it passes through. The result is sparse activation: the model’s total parameter count can be very large while the number of parameters active for any single token stays small. Capacity grows without per-token compute growing in proportion.
The critical property for this comparison: MoE is a training-timearchitecture. The router and the experts are trained together, inside one set of weights, by whoever builds the model. From the caller’s side of the API there is nothing to configure and nothing to see — an MoE model presents as one model, full stop. Open-weight releases in the Mixtral and DeepSeek families popularized the pattern and made it inspectable, which is why those names anchor most MoE explanations.
One caution on the vocabulary: “expert” suggests a math specialist and a law specialist taking turns. That is not what the routing learns. Expert assignment is per-token, learned end-to-end, and typically uninterpretable — the experts are specialists in the statistical sense, not the departmental one.
Mixture of Agents: aggregation across models
MoA operates one level up. The Mixture-of-Agents paper (Wang et al., 2024) formalized the pattern: several proposer models draft answers to the same prompt in parallel; in subsequent layers each model reads the previous layer’s drafts and revises; an aggregator model writes the final answer. Nothing is trained. Everything happens at inference, with off-the-shelf models, and any developer with API access can build it.
Because membership is a runtime choice, it is also a live research question. Self-MoAreported that aggregating multiple samples drawn from a single strong model can outperform mixing different models — evidence that a mixture’s value depends on what is being mixed, not on diversity for its own sake. A full walkthrough of the MoA architecture, including where it earns its cost and where it does not, is in What is Mixture-of-Agents?
The difference in a table
| Dimension | Mixture of Experts | Mixture of Agents |
|---|---|---|
| Level | Inside one model: sub-networks within one set of weights | Across whole models: separate systems, separate calls |
| When applied | Training time; fixed once the model ships | Inference time; reconfigurable per request |
| Who controls it | The lab that trains the model | The application developer or orchestration layer |
| Cost profile | Lower compute per token than a dense model of equal total size; invisible in the price of a call | Multiplies inference calls per query; every draft and aggregation step is billed |
| Visible to the caller | No — one API call, one model | Yes — members, layers, and aggregation are choices |
Why the two get confused
The collision is mostly linguistic. Both names follow the “mixture of X” template, both abbreviate to a three-letter acronym starting with Mo, and both are sold on the same intuition: many specialized parts outperform one generalist. Search for either term and the other surfaces. As multi-agent orchestration hardens into a product category of its own — Gartner now tracks multiagent orchestration platforms as a market — the “mixture” vocabulary appears in vendor copy at both levels of the stack, which does not help.
The reliable test is a question about change: if altering the behavior would require training a new model, the mechanism is MoE. If it is a configuration change in an orchestration layer — swap a member, add a sample, change the aggregation rule — it is MoA. One is a property of weights; the other is a property of workflow.
Where MoA aggregation fails: the selection bottleneck
For a developer, the open problem in any MoA design is the last step: something has to turn several candidate answers into one. Moamao’s published v1 research tested that step directly and found it to be the failure point. Across six mixture architectures where the correct answer was provably present in the candidate pool, every architecture scored at or below its own best member when a small model acted as the judge. The candidates were not the problem; the judging was. A second finding compounds it: auxiliary instructions anywhere in a prompt measurably degrade knife-edge, sequential answers — so even the scaffolding used to ask a model to compare candidates carries a cost. The full write-up is at Never let a small model choose.
The fix that shipped in Moamao’s production architecture is judge-free aggregation. Two candidate pools run server-side, and they are merged by one deterministic bit — did code substitute a computed value — rather than by any model reading and ranking answers. No model ever compares outputs. On our frozen benchmark suite, that dual-pool architecture, running on a single consumer 8GB GPU with a qwen3:8b base, scored 10 of 10 on the frozen ten-task tier-1 reasoning, context, and memory suite, replicated across eight consecutive runs — the same 10 of 10 that claude-opus-5 scores on that suite under the same harness. The composite across all frozen suites is 14.75 of 17 (87 percent) against Opus’s 17 of 17, at roughly ten seconds per task. The benchmark files are hash-locked, the predictions were pre-registered, and three earlier claims were retracted the same day the errors were found.
A related measurement from the same work: a single well-orchestrated 8B model matched a two-model panel at 4.6 times the speed — One model vs a panel walks through that result. The whole mixture runs behind one API call on hardware Moamao owns; the architecture is described on the product page and the broader orchestration approach on the orchestration page.
FAQ
Is GPT-4 a mixture-of-experts model?
MoE architectures are widely believed — and have been repeatedly reported — to power some frontier models. None of the labs involved has officially confirmed architectural details, so the claim should be treated as informed speculation rather than established fact. The pattern is only verifiable where weights are open, as in the Mixtral and DeepSeek-class releases.
Can you combine MoE and MoA?
Yes, and there is no tension in doing so. The two mechanisms are orthogonal: MoE lives inside a model’s weights, MoA operates across models at inference. An MoA pool populated with MoE members is architecturally unremarkable — the router inside the weights and the orchestrator outside them never interact.
Which one should a developer care about?
In practice it is not a choice. MoE is decided by whoever trains the model, and the caller cannot turn it on or off. The lever that exists at the application layer is orchestration: which models run, how many samples are drawn, and — the part the evidence says matters most — how the results are aggregated.
Related: What is Mixture-of-Agents?, One model vs a panel, Never let a small model choose, and multi-agent orchestration platforms.