Mixture-of-Agents: How Ensemble Reasoning Works

The Problem with One Model

A single language model has a characteristic failure mode: it reasons from a single perspective. Given a hard architectural question, it may commit confidently to a framing that a second model would immediately challenge. Given ambiguous requirements, it may resolve the ambiguity one way and never consider the others. These are not bugs in the model — they are properties of how large language models are trained. Any given model has learned to express one coherent view of the world, not to argue with itself.

Mixture-of-Agents is the answer to that limitation. Instead of one model reasoning about a problem, several models reason about it independently, and a fourth model synthesizes their perspectives. The synthesizing model — called the aggregator — sees the analysis from all of the contributing models — called reference models — before it produces any output. The result is qualitatively different from any single model's answer: it incorporates disagreements, catches blind spots, and often produces conclusions that none of the reference models reached on their own.

In v0.18, this capability became a first-class part of Hermes. You select an MoA configuration the same way you select any other model. The reasoning is visible. The aggregator streams live. Nothing about the familiar agent loop changes.

The Two Roles: Reference Models and the Aggregator

Understanding MoA starts with the two-role architecture. Every MoA configuration has exactly one aggregator and one or more reference models.

Reference models receive the conversation text but not the tool schemas. They cannot call tools. Their job is purely analytical: read the conversation, reason about the problem, and produce a response. Each reference model runs independently — it does not see what the other reference models are saying while it thinks. Their outputs arrive as private context for the aggregator before the aggregator does anything.

The aggregator is the model that actually acts. It receives everything: the original conversation, the full tool schemas, and the reference models' outputs (appended as labeled context blocks). It is the only model in the configuration that calls tools, writes files, runs commands, or produces the response you see. From Hermes' perspective, the aggregator is the agent. The reference models are advisors.

This two-role design is deliberate. Reference models are cheap to run — they see less input (no tool schemas) and their output is capped. The aggregator pays the full cost of a tool-capable model call. The quality gain from having multiple analytical perspectives costs far less than running the aggregator multiple times.

The MoA Agent Loop, Step by Step

When you send a message with an MoA preset active, here is exactly what happens:

• Step 1. Hermes resolves the named MoA preset — it knows which models are reference models and which is the aggregator.
• Step 2. Reference model calls execute in parallel. Each reference model receives the conversation text only, without tool schemas. Their generation runs independently — they cannot see each other's outputs.
• Step 3. Reference outputs are appended to the conversation as labeled private context blocks. You see these in the terminal or TUI as distinct blocks attributed to each reference model. This is new in v0.18 — in earlier versions, ensemble outputs were opaque.
• Step 4. The aggregator call executes with the full context: original conversation, tool schemas, and all reference outputs. The aggregator reasons over all of it before producing its first token.
• Step 5. The aggregator streams its response, calling tools as needed. Tool execution proceeds exactly as in a normal Hermes session.
• Step 6. If the task requires additional turns (tool results, follow-up reasoning), the MoA process repeats: reference models run again with updated context, then the aggregator synthesizes and continues.

The key insight is that step 2 and step 4 use completely different execution contexts. Reference models are advisors with no agency. The aggregator is the agent with full agency and the benefit of multiple perspectives.

Why Visibility Matters

Before v0.18, if you ran an MoA configuration in Hermes, the ensemble reasoning happened behind the scenes. You got the aggregator's output and had no way to inspect what the reference models said — or whether they disagreed. In v0.18, every reference model's output appears as a visible, labeled block before the aggregator responds.

This matters for debugging and trust. When a complex architectural decision goes well, you can look at which reference model's framing the aggregator adopted. When the aggregator takes an unexpected path, you can check whether any reference model flagged the concern. Visible reasoning is auditable reasoning.

The /moa One-Shot Command

You do not need to switch your session model to use MoA for a single turn. The /moa <prompt> slash command runs one turn through the default MoA preset and then restores whatever model you had before. This is useful for spot-checking hard decisions without committing to the higher per-turn cost of a full MoA session.

For example: you have been working on a refactoring task with a fast, cheap model. You reach the point of choosing between two architectural approaches. You run /moa which of these two approaches handles the edge case on line 47 more safely? The three-model ensemble evaluates the question. When the aggregator responds, your session model reverts to the original cheap model.

When MoA Beats a Single Model

Benchmarks on hard tasks show an MoA configuration using Claude Opus 4.8 as the aggregator — with gpt-5.5 and DeepSeek V4 Pro as reference models — outperforming Opus 4.8 alone by roughly six points. That is a meaningful gap on difficult reasoning tasks. On simple tasks, the gap is negligible.

MoA is worth the added latency and cost when: the problem is genuinely complex and ambiguous; getting it wrong is expensive; or you need the reasoning to be auditable. It is not worth it for routine tasks: writing a test for a simple function, renaming a variable, or summarizing a log file. The added per-turn cost of running multiple models in parallel means you want to be selective about when you engage the ensemble.