Mixture-of-Agents (MoA) — stacking LLMs in layers so they sharpen each other

For NAO + anyone building multi-model systems. This is the deep companion to [[fusion-and-llm-councils]]. Where that article explains why a panel of models beats one, MoA is the specific, benchmark-topping architecture for doing it: not one council round, but several layers of councils stacked, each layer reading everything the layer below produced. Sourced from the Together AI / Wang et al. 2024 paper (arXiv:2406.04692), the Together blog + docs, the reference repo, and a 2025 adversarial-robustness follow-up.

The one-sentence idea

Run a panel of LLMs, feed all their answers to another panel, feed *those* answers to a final aggregator — repeat for a few layers — and the open-source stack beats GPT-4 Omni. (Junlin Wang, Jue Wang, Ben Athiwaratkun, Ce Zhang, James Zou — Together AI / Duke / Stanford, June 2024; arXiv:2406.04692.)

The headline result: a MoA built entirely from open-source models scored 65.1% on AlpacaEval 2.0 (length-controlled win rate) versus 57.5% for GPT-4 Omni — a +7.6-point absolute lead, with no proprietary model in the loop (Together blog, together-moa).

Why it matters

[[fusion-and-llm-councils]] establishes the base fact: errors of independently trained models are partly independent, so a judge that reconciles them cancels noise. MoA matters because it answers the next two questions:

1. How deep should you go? Fusion is usually one round (dispatch → judge → synthesize). MoA shows that iterating the panel — using one layer's synthesized answers as the input references for the next layer — gives monotonic gains per layer (Together blog, Architectural Validation). It's the difference between "ask a committee once" and "circulate the draft through several committees, each improving on the last."

1. Do you even need a frontier model? No. The paper's central, slightly uncomfortable finding — they call it collaborativeness — is that an LLM generates better responses when shown other models' answers, even when those other answers came from weaker models (paper §"collaborativeness"). The aggregator is doing genuine synthesis, not selection, so a stack of mid- tier open models out-reasons a single top model.

For OpenAlice this is directly load-bearing: it's the architectural blueprint behind the M11 model-council / fusion super-feature and is already implemented in hermes-agent (see "How it connects").

How it works (the real mechanics)

Two roles, not one

MoA splits the council members into two roles (Together blog):

• Proposers — generate diverse candidate answers. Their value is not being individually correct; it's offering "nuanced and different perspectives that serve as valuable references." A weak-but-different proposer is still useful.
• Aggregator — synthesizes the proposers' answers into one high-quality response. This is the capability-sensitive role; you want your strongest model here.

Crucially, the same model can play both roles in different layers, and a model that's a good aggregator is usually also a good proposer (the paper's proposer-vs-aggregator analysis).

The layered structure (formal)

The architecture is l layers × n agents per layer. For layer i, the output is (paper, eq. for MoA):

y_i  =  ⊕_{j=1..n} [ A_{i,j}(x_i) ]  +  x_1
x_{i+1} = y_i

In prose:

• A_{i,j} is the j-th agent (an LLM, possibly with its own decoding params) in layer i. It's run on the current layer input x_i.
• + is text concatenation with the original user query `x_1` — every layer always re-sees the real question, so the chain can't drift off-topic.
• ⊕ is not a sum — it's "apply the Aggregate-and-Synthesize prompt": glue the agents' outputs together as numbered references inside a system prompt that tells the next model to synthesize, not copy them.
• The final layer is typically a single aggregator producing the answer.

So a "3-layer, 6-proposer" MoA is: 6 models answer the question → their 6 answers become references → 6 models answer again with those references → their answers become references → a final aggregator writes the response. Each layer is a full fusion round; MoA is fusion stacked.

The Aggregate-and-Synthesize prompt (verbatim)

This single prompt is the entire "magic." It's identical in the paper, the Together repo, and (verified) the OpenAlice hermes-agent implementation:

You have been provided with a set of responses from various open-source models
to the latest user query. Your task is to synthesize these responses into a
single, high-quality response. It is crucial to critically evaluate the
information provided in these responses, recognizing that some of it may be
biased or incorrect. Your response should not simply replicate the given answers
but should offer a refined, accurate, and comprehensive reply to the
instruction. Ensure your response is well-structured, coherent, and adheres to
the highest standards of accuracy and reliability.

Responses from models:
1. <response one>
2. <response two>
...

The reference responses are injected as a numbered list appended to that system prompt (inject_references_to_messages in the repo: each reference prepended with \n{i+1}. , injected only when the list is non-empty). The instruction to "critically evaluate… some may be biased or incorrect… do not replicate" is what turns concatenation into synthesis — and, as we'll see, is also what the adversarial follow-up tries to exploit.

The reference configurations

The paper / Together blog ship two named recipes (Together blog, Configuration):

(The Together docs keep this recipe current — as of 2026 the default reference list has rotated to e.g. Qwen3.5, Llama-3.3-70B, DeepSeek-V3.1, MiniMax-M2.x, temperature 0.7 — but the architecture is unchanged.)

The numbers (cross-checked across paper + blog)

AlpacaEval 2.0, length-controlled win rate:

• MT-Bench: MoA 9.25 ±0.10, MoA w/ GPT-4o 9.40, vs GPT-4o 9.19. (MT-Bench is near-saturated, so the gains are small but consistent.)
• FLASK: MoA beats the strongest single proposer (Qwen1.5-110B) on robustness, correctness, factuality, completeness, insightfulness, metacognition — and slightly loses on conciseness (synthesis tends to produce longer answers, an honest tradeoff).

Key ideas & tradeoffs

• Synthesis > selection. An LLM-ranker baseline that just picks the best of the proposed answers underperforms the aggregator that writes a combined one (Together blog, Architectural Validation). The aggregator pulls good fragments from multiple answers, including from answers that were worse overall — confirmed by the collaborativeness analysis: positive Spearman correlation between an aggregator's output and the higher-quality proposed responses across BLEU / Levenshtein / TF-IDF similarity. It incorporates the best parts, not the whole of any one answer.

• Diversity of proposers beats more samples of one. Six different proposers (61.3%) beat six samples from a single model (56.7%). Different model lineages = more independent errors to cancel. (This dovetails with the self-fusion result in [[fusion-and-llm-councils]]: even one model sampled twice helps — but different models help more.)

• Depth helps, with diminishing returns. More layers → monotonic gains, but each layer is another full fan-out of LLM calls. Practically: 2 layers (MoA-Lite) already matches GPT-4o; 3 is the published sweet spot.

• Cost can be a *win*, not just a cost. Pareto-front analysis (paper Fig. 5, Together + OpenAI May-2024 pricing): MoA-Lite matches GPT-4o's cost while beating its quality by ~1.8 points; several MoA configs hit GPT-4-Turbo-level quality at ~2× lower cost. Open-weight token prices make the ensemble cheaper than one closed frontier call. (Mirrors the "budget panel beats frontier for half the price" finding in [[fusion-and-llm-councils]] — and is exactly why MoA is a real lever, not just an academic flex; see [[model-routing]].)

Honest caveats & limitations

• Latency is the real tax. Authors explicitly flag slower time-to-first- token as the headline downside (Together blog, Limitations). Layers are sequential — layer i+1 can't start until layer i finishes — so a 3-layer MoA serializes 3 rounds of the slowest proposer in each layer. You can fan out within a layer in parallel, but you cannot parallelize across layers. This makes MoA unsuitable for interactive/low-latency turns; it's a "hard problem, worth the wait" tool, same caveat as fusion.

• Verbosity / conciseness regression. Synthesis inflates length (the FLASK conciseness dip). On length-controlled metrics this is corrected for; in production it's a real UX cost.

• Aggregator is a single point of failure. Quality concentrates in the final aggregator. A weak aggregator wastes good proposals.

• It's an *inference-time* method, not training. No weights change; you pay the full multi-model cost on every query. There's no amortization — unlike a distilled or fine-tuned model.

• Adversarial fragility — the big one. A 2025 follow-up, "This Is Your Doge, If It Please You: Exploring Deception and Robustness in Mixture of LLMs" (arXiv:2503.05856), shows MoA is brittle to a single deceptive proposer. Injecting one carefully-instructed deceptive agent into a 6-agent / 3-layer MoA dropped performance from 49.2% → 37.9%, erasing essentially all MoA gains. The very "critically evaluate, some may be incorrect" prompt that enables synthesis does not reliably make the aggregator reject a confidently-wrong reference; the deception propagates up the layers. This is a direct consequence of the architecture: every layer re-reads every prior output, so a poisoned answer keeps getting re-presented. Defenses explored (larger/stronger aggregators, limiting information availability) help only partially. Takeaway for production: only trust proposers you control. A MoA panel of untrusted/third-party agents is an attack surface, not just a quality boost.

• Benchmarks are LLM-judged. AlpacaEval 2.0 and MT-Bench use an LLM judge; length-controlled win rate corrects length bias but not all judge biases. The +7.6 headline is real and replicated, but it's "preferred by a judge," not a ground-truth correctness measure.

How it connects to OpenAlice

This isn't theoretical for us — MoA is already shipped in the ecosystem and is the named architecture behind a roadmap super-feature.

1. `hermes-agent` has a working MoA tool. tools/mixture_of_agents_tool.py implements the paper directly: a parallel fan-out of reference models via OpenRouter (currently claude-opus-4.6, gemini-3-pro-preview, gpt-5.4-pro, deepseek-v3.2) → a single aggregator (claude-opus-4.6) using the verbatim Aggregate-and-Synthesize system prompt above. It uses REFERENCE_TEMPERATURE=0.6 (diversity) and AGGREGATOR_TEMPERATURE=0.4 (focused synthesis), with MIN_SUCCESSFUL_REFERENCES graceful-degradation so a dead proposer doesn't kill the call. It's pitched in-code as the "extremely-difficult-problem" tool (coding, math, complex analysis) — i.e. the selective scalpel, exactly as MoA's latency cost dictates. It's currently a 1-layer MoA (parallel proposers → aggregator); multi-layer iteration is marked as a future enhancement in the module docstring, which matches the paper's "depth gives monotonic gains" finding as the obvious next step.

1. MoA is the deep form of M11. [[fusion-and-llm-councils]] describes M11 as configurable panel + vote/judge/synthesize aggregation, built on M10's provider-router. MoA is precisely M11 with `synthesize` + multiple layers. The router already gives us "call N models in parallel, then aggregate"; MoA says "then feed that back in and do it again." When M11 wants its strongest mode for the hardest tasks, MoA-3-layer is the design — and hermes-agent's tool is the prototype to lift from.

1. Codex-as-a-voice fits the proposer role. NAO's rule (per [[fusion-and-llm-councils]]) — Claude is the cheap default executor, Codex is reserved as one distinct council voice — maps cleanly onto MoA's proposer/aggregator split: Codex's different lineage makes it a high-value proposer (diversity is the whole point), while a strong Claude (Opus 4.6) sits in the capability-sensitive aggregator seat. Diversity where it's cheap, capability where it counts.

1. The deception finding is a real guardrail for us. Because Alice can route to and ingest third-party model output, the Doge result is a concrete security constraint: never put an untrusted model in a proposer slot of a synthesis stack — a single deceptive proposer can dominate the aggregator. Keep MoA panels to provider-vetted models (the OpenRouter frontier set we control), and treat the aggregator prompt's "may be incorrect" clause as insufficient defense, not a safety net. This is the multi-agent analogue of the prompt-injection discipline already in our HITL/safety stack.

1. Adjacent in the library. MoA is the "many models, layered" point in the same constellation as: [[fusion-and-llm-councils]] (one-round fusion + the council pattern), [[model-routing]] (picking which model per task — MoA's proposer-set selection is a routing decision), [[agent-memory-systems]] / [[mempalace]] (what state agents carry between turns — orthogonal to MoA, which is stateless-per-query), [[graphrag]] / [[graphify]] (retrieval feeding the proposers' context), and the build-it-yourself trio [[microgpt-build-an-llm-from-scratch]] / [[llm-from-scratch]] / [[llm-maintained-wiki]] for the underlying models and this very wiki pattern.

Takeaways

1. MoA = fusion, stacked. Layers of proposer panels, each reading all prior outputs, then a final aggregator. y_i = ⊕[A_{i,j}(x_i)] + x_1.
2. Collaborativeness: models write better answers when shown other models' answers — even weaker ones. Synthesis, not selection.
3. Open-source MoA (65.1%) beat GPT-4o (57.5%) on AlpacaEval 2.0 — and can be cheaper than one frontier call.
4. Costs: serialized layers → slow TTFT; verbose; pay full cost every query; aggregator is a single point of quality.
5. Security: a single deceptive proposer erased nearly all gains (49.2→37.9%). Only ever stack models you trust.
6. For us: it's already in hermes-agent, it's the deep mode of M11, and the proposer/aggregator split is the natural home for the Codex-as-a-voice rule.

See also [[fusion-and-llm-councils]] (the council/fusion foundation), [[model-routing]], and [[mixture-of-agents]]'s siblings in the lab library.