The Council — ตรวจก่อนส่ง ทุกคำตอบThe Council — Check Before Deliver

🤔 If the agent answers wrongly and nobody checks before the answer reaches you — when exactly do you find out? The question is not about distrusting models. It comes from a plain fact: a wrong answer and a right one arrive on your screen looking exactly the same.

The previous post — #3 Profiles — One Agent per Role — split the agent into several roles, each with its own home directory, SOUL.md, memory and model.^[6] The next question follows naturally: now that we have several roles, can one of them check the work of another before that work reaches us?

The one-line answer for this post is that Hermes has no /council command — but what readers mean by "a council" is genuinely buildable out of three official mechanisms that already ship in Hermes Agent v0.21.0: Mixture of Agents (several models deliberate before the answer), /review (an independent reviewer checks the work before you accept it), and /goal (a contract in which "done" means evidence). This post builds all three, one command at a time, and names the cost of each.

1. There Is No /council — What "Council" Means in Hermes

Let me answer plainly first, because there is a fair amount of wrong information circulating: Hermes Agent v0.21.0 (tag v2026.8.31) has no /council command. The whole slash-command reference page does not contain the word,^[3] and a GitHub code search for "council" across the repository returns a single hit, in an unrelated test file.

What confuses people is that it did exist — for about two hours. PR #84904, titled "Model Council mode — user-facing multi-model deliberation (/council)", merged on 2026-08-13 at 02:44 UTC. It added a per-preset synthesis_style field (guidance by default, or council) and a /council command in which "reference models answer independently and the acting model chairs the deliberation, delivering a user-facing report of consensus, per-model disagreements (with the differing assumptions behind them), unique contributions, and a recommendation with an explicit confidence level".^[10] PR #84994 then reverted the whole thing the same day at 04:50 UTC — 10 files, +24/−407.^[10]

The v0.21.0 release notes therefore say so directly, under the heading "Reverted in this window (not shipping)": "Model Council mode (/council) — landed then reverted; not in this release."^[8] I labour this because several posts and videos written during that week still discuss /council as if it were a working feature. If you type it and nothing happens, your machine is not at fault.

But the "council" readers actually want is not a command name. It is a mechanism that puts more than one opinion in front of an answer before the answer reaches you — and Hermes already has three of those, each under its own official name.

• Mixture of Agents (MoA) — several reference models answer privately first, and one synthesising model then acts and writes the real answer.^[1]
• /review — an independent reviewer subagent with the full toolset is dispatched to inspect the work product the conversation just made, and reports back into the same chat.^[2]
• /goal completion contract — a contract whose judge declares done only when the verification criterion has been met with concrete evidence, rather than on a claim of completion.^[4]

The three sit at different layers and do not substitute for one another: MoA works inside a single turn, while /review is a separate subagent working in the background. Anyone who wants the full map of Hermes' multi-agent layers has it in the analytical post Hermes #2 Agent Teams, which walks all four — in-session subagents, the Kanban board, Bot Mode with A2A, and multi-profile serving — and already makes the point there that MoA is not delegation but a "virtual model provider". I will not repeat that here; here we build the thing on the Hermes Desktop screen.

2. How Mixture of Agents Works

MoA is a virtual model provider. The official page opens on exactly that sentence: "Mixture of Agents is a virtual model provider. Each named MoA preset appears as a selectable model under the moa provider."^[1] Translated into something operational: a preset you name shows up in the model picker as if it were a model — in the CLI, the TUI, Hermes Desktop and the gateway alike.

The most common misreading is that every model in the preset helps write the answer. It does not work that way. Within one model call, Hermes does this:^[1]

1. resolves the selected preset by name;
2. runs the reference models without tool schemas — they see only the conversation's user/assistant text, not Hermes' system prompt and not the tool-call transcript;
3. appends the reference outputs as private context for the aggregator;
4. calls the configured aggregator with Hermes' normal tool schema;
5. treats the aggregator's response as the real model response, and if it calls tools, Hermes executes them normally;
6. on the next iteration the same process runs again over the updated conversation, tool results included.

The references advise; the aggregator acts

Two practical consequences follow. First, the aggregator is "the acting model" — it writes the reply and it is the only slot that can call tools. Second, the reference models never answer the user directly; they are advisors speaking only to the aggregator.^[1] So a preset's quality depends on the choice of aggregator far more than on the number of advisors.

The docs give the reason the references get no tool schema outright: so that "reference calls stay cheap and avoid strict-provider rejections".^[1] Cheaper, and safe against providers that validate schemas strictly. That is also why a small model, or a model running on your own machine, can take an advisor's chair even if it is not much good at tool calling.

First-class since v0.18.0

MoA is not new in this release. It became first-class in Hermes Agent v0.18.0 (tag v2026.7.1, published 2026-07-01), the release the team named "The Judgment Release". The notes say every preset "shows up as a selectable model under a moa provider, right alongside Claude, GPT, and Grok in every model picker (CLI, TUI, desktop, gateway)".^[9] The same release made each reference model's output render "as its own labelled block" with the final answer streaming live — and my favourite line in those notes: "You get to watch the committee deliberate, not just read the verdict."^[9]

💡 The numbers the docs publish: the MoA page reports HermesBench results for a two-model preset — claude-opus-4.8 aggregating over a gpt-5.5 reference — at 0.8202, against 0.7607 for anthropic/claude-opus-4.8 alone and 0.7412 for openai/gpt-5.5 alone.^[1] The caveat is that this is Nous Research's own internal benchmark, not a third-party measurement, and the page publishes neither the method nor the task set — so I read it as evidence that the direction is right, not as a number to put on a slide.

3. Procedure — Build the Council

A working council takes a few minutes to build. Create a preset called council with the interactive helper in a terminal, choose two or three reference models and one aggregator, then select that preset in Hermes Desktop's model picker. Every command below works on every surface, not only on the Desktop.

1. Open a terminal and look at what you already have with hermes moa list — you will see the shipped preset named default with its reference models and its aggregator.^[1]
2. Create the new preset with hermes moa configure council — the docs describe hermes moa configure [name] as the command that will "create or update a named preset".^[1] The helper asks for a provider first, then for a model from that provider.
3. Pick the reference models one at a time; the screen asks each time whether you want to add another. I would take two or three that think differently, because three advisors who always agree tell you no more than one advisor does.
4. Pick the aggregator last, and make it the strongest model you have access to — it is the slot that writes the answer and makes the real tool calls.
5. Check the result with hermes moa list again, and compare it against what actually landed in config.yaml, in the shape shown below.
6. In Hermes Desktop, open the model picker in the composer — the MoA page states that the dropdown carries an MoA presets section, and that selecting one switches the active model to MoA: council.^[1] If you would rather type, /model council --provider moa does the same thing.
7. Ask a real question — one that has several plausible wrong answers. A question that cannot be answered badly will never show you whether the council is working.
8. Read each reference model's labelled block first, and only then the synthesised answer. The order matters: read the verdict first and you will agree with it, then read the advisors looking for confirmation.
9. To ask the council a single question without changing your session's model, use /moa <prompt> — the docs describe it as running one prompt through the default preset and then restoring your model, "One-shot — does not change your session model", and note that a bare /moa simply prints usage.^[3]
10. When you have an answer you like, do not accept it yet — type /review to send an independent reviewer at that work product, as described in section 5, and only then decide whether to accept it, steer it, or stop it.

If you would rather write it than click it, ~/.hermes/config.yaml takes a preset in this shape. Every key and every value below is taken directly from the MoA documentation page and from the defaults in hermes_cli/config_defaults.py.

moa:
  default_preset: council      # the preset /moa uses when no name is given
  active_preset: ""            # default is empty = no preset forced on every session
  save_traces: false           # true = write every turn's trace as JSONL
  presets:
    council:
      reference_models:
        - provider: openai-codex
          model: gpt-5.5
        - provider: openrouter
          model: deepseek/deepseek-v4-pro
      aggregator:
        provider: openrouter
        model: anthropic/claude-opus-4.8
      max_tokens: 4096
      fanout: user_turn        # advisors run once per user message
      enabled: true            # false = no fan-out, the aggregator acts alone

Can a local model take a seat on the council?

Here is what the documentation actually supports. The MoA page says "The config stores explicit provider/model pairs, so you can mix providers and use multiple models from the same provider",^[1] and the Local Models page says that selecting a local model as your main model uses model.provider: llamacpp, which is "the same shape as every other provider".^[5] The only slot restriction the docs state is that an aggregator may not be another MoA preset — recursive MoA trees are deliberately blocked.^[1]

Structurally, then, a model from #2 Local Models can sit as an advisor, and the advisor's chair is the one that suits it best, since advisors receive no tool schema. But I have to be explicit: the documentation gives no example of a local provider inside an MoA preset. Every example on that page uses a cloud provider. So treat this as something the structure supports and you should test yourself, not as a recipe I can vouch for on the documentation's behalf.

4. Reading What the Council Said — Labelled Blocks, Failures and Traces

What makes MoA a council you can watch rather than a black box is that every reference model's output is rendered as its own labelled block before the synthesised answer streams. The v0.18.0 notes describe reading "what GPT-5 thought, what Claude thought, and what Grok thought, before the aggregator synthesizes them into one answer", and name three surfaces: the CLI, the TUI and the desktop app.^[9] Note that those notes do not mention the gateway messaging platforms, so I will not claim these blocks render on Telegram or Discord.

Four behaviours are worth knowing before you rely on this, because each changes what you see on screen.

• A failed advisor does not fail the turn — the docs state that "Credential failures on one reference model do not abort the turn. Hermes includes the failure in the reference context and continues with whatever models returned."^[1] So an expired API key on one advisor still gets you an answer — and this is the trap I most want to flag, because a three-seat council can quietly become a two-seat one without your noticing.
• enabled: false turns the fan-out off — set it on a preset and "the aggregator acts alone, exactly as if you selected it as a plain model".^[1] It is a temporary off switch that does not require deleting the preset.
• The model-call count definitely rises — the docs say so in their Notes section: "MoA increases model-call count. A single model iteration can involve multiple reference calls plus the aggregator call."^[1]
• save_traces records every turn — it defaults to false; switched on, Hermes writes "each MoA turn (reference + aggregator exact input/output/usage) as JSONL" to <hermes_home>/moa-traces/<session_id>.jsonl, or to the directory named in moa.trace_dir.^[6]

That <hermes_home> in the last line matters more than it looks. If you work under a profile, as in the previous post, its home is ~/.hermes/profiles/<name>/ and not ~/.hermes/ — the Profiles page states that a profile "is a separate Hermes home directory" and that the wrapper sets HERMES_HOME before launching hermes.^[6] Your council's traces pile up inside that profile's home.

5. The Second Check: /review

MoA checks the thinking before the answer is written; /review checks the work after the answer exists. The docs describe it as spawning "an independent, full-privilege background subagent whose only job is to review the work your conversation just produced — a PR, a diff, code, documentation, a design", and say it works "on every surface: CLI, TUI, the Desktop app, and every gateway messaging platform".^[2]

Five details change how you actually use it.

• The starting evidence is the last ten messages — "The last 10 user/assistant messages are snapshotted as the reviewer's starting evidence (tool output and system messages are excluded)".^[2] Tool output does not count, so if the work lives purely in tool results, have the agent summarise it in a message before you call the review.
• The reviewer has real tools; it does not judge from text — the subagent gets "the full normal subagent toolset (terminal, web, files, browser...), so it actually opens the PR, reads the diff, and runs code rather than judging from the excerpt".^[2]
• The reviewer inherits the project's rules — any skills the primary agent had loaded are named in its briefing with an instruction to load them and judge the work against their conventions, and its system prompt embeds the workspace's context files, AGENTS.md / CLAUDE.md / .cursorrules, as binding conventions.^[2]
• The report lands back in the same chat — "its full review re-enters the same session as a normal background-subagent completion", which means the primary agent sees it and can start fixing straight away.^[2]
• It is not /refine — the docs separate them explicitly: /refine reviews the conversation to update memory and skills, while /review reviews the work product the conversation created.^[2]

The routine I actually use on anything I am about to hand to another person has four steps and costs me under a minute.

1. Let the agent work until there is a tangible artifact — one PR, one diff, or one document.
2. Type a bare /review to review whatever the last ten messages presented, or add instructions the way the docs show: /review focus on security.^[2]
3. While you wait, type /agents (alias /tasks) to see the agents and running tasks in the current session.^[3]
4. If the reviewer heads the wrong way, correct it mid-flight — since v0.21.0 delegate_task accepts {"action": "steer", "subagent_id": "...", "message": "..."} to queue a course correction without stopping the child, and {"action": "stop", "subagent_id": "..."} to end it at the next iteration boundary, with the partial result still re-entering the conversation as a normal completion.^[2]

Pin the reviewer's model

By default the reviewer runs on the same model as the main agent, and that is the default I would change, because the same model tends to miss the same class of mistake. In ~/.hermes/config.yaml, pin it in the auxiliary.review block.

auxiliary:
  review:
    provider: openrouter               # or nous, anthropic, a direct base_url, ...
    model: anthropic/claude-opus-4.6   # a strong reviewer model

The default in the source is {"provider": "auto", "model": "", "base_url": "", "api_key": "", "api_mode": ""}, with the in-file comment stating that "auto" plus "" means the "main agent's model", and that api_mode forces the transport among chat_completions, anthropic_messages and codex_responses.^[6]

💡 The rule Hermes wrote for itself: the bundled skill requesting-code-review (version 2.0.0) states its core principle in one line — "No agent should verify its own work. Fresh context finds what you miss."^[7] That sentence is the entire reason the reviewer-model pin exists, and the reason I do not recommend leaving it on auto.

On versions, let me be exact: /review merged into main through PR #93339 on 2026-08-24 at 00:38 UTC.^[11] The first tagged release after that date is v0.20.6 (tag v2026.8.27) — but neither the v0.20.6 nor the v0.21.0 release notes contain the string /review at all. So all I can say is that it has been in main since 2026-08-24 and is in the current documentation; no release note confirms which tagged release first carried it.^[8]

6. Define Done as Evidence: /goal

The third check does not inspect the answer; it inspects the word "done". /goal is a standing objective Hermes works toward across turns, with a judge model checking after every turn — and when you attach a completion contract, the judge's prompt changes so that it decides done "only when the verification criterion is met with concrete evidence (a command result, file excerpt, test output) — not a loose 'looks done' claim".^[4]

There are two ways to write the contract. The first is to have Hermes draft it with /goal draft <text>, which the docs recommend as the main route. The second is to write it yourself as field: value lines, exactly as the documentation shows.

/goal Migrate auth to JWT
verify: pytest tests/auth passes
constraints: keep the /login response shape unchanged
boundaries: only touch services/auth and its tests
stop when: a DB schema migration is required

The first non-field line is the goal's headline, and the recognised field prefixes include verify:, verified by:, constraints:, preserve:, boundaries:, scope:, stop when: and blocked:. The docs also note that a plain goal with an incidental colon, such as Fix bug: the parser drops commas, is not mangled, because only known prefixes are pulled out.^[4]

• /goal show — print the active goal's completion contract so you can read it.^[4]
• /goal gate add scripts/run_tests.sh tests/hermes_cli/test_goals.py — add a quality gate, a shell command that must exit 0 before the goal can complete at all. The docs state that gates run before the judge, and that if a gate fails the judge is not called.^[4]
• /subgoal <text> — append a criterion mid-loop without resetting it; the judge will not mark the goal done until the original objective and every subgoal are met.^[3]

The limitation to know, and the docs state it themselves, is that the judge fails open — the page states that "If the judge errors (network blip, malformed response, unavailable aux client), Hermes treats the verdict as continue — a broken judge never wedges progress."^[4] If the judge model dies, the loop continues rather than stopping. That is precisely why a quality gate made of a real shell command is stronger than a contract made of prose, and why I always use the two together.

If the work that needs checking is work nobody is watching — scheduled jobs, background runs, an agent working overnight — the closer mechanism is verify-on-stop, which refuses a final answer on a turn where the agent edited code without producing fresh verification evidence, plus the pre_verify hook that lets a plugin inject your own policy at the same point. Both are the full subject of #6 Automation & Agents, so I will leave the link here rather than tell that story twice.

7. Cost and Speed Knobs

A council has a price, and the price is straightforward — you pay for the advisors' model calls every time they speak. The docs state that the wait per turn is set mainly by the advisors, "Advisor generation is the dominant per-turn latency", because the turn waits for the slowest advisor to finish writing.^[1] The table below is every knob you can actually turn, with the defaults as they appear in the documentation and in config_defaults.py.

That last row is what makes "a council where every seat runs a different model" unbuildable out of subagents — and it is not a technical gap awaiting a fix but a declared maintainer policy. Closing the /council request in issue #37569 on 2026-07-13, teknium1 wrote that the proposal "assigns distinct provider/model pairs to individual proposer, critic, chairman, and delegated subtask calls", which is the per-call model routing covered by the standing delegation-model-routing policy, and restated that "subagent models are not selectable per call; the supported configuration is a single global delegation.provider / delegation.model override".^[12]

The design conclusion is therefore unambiguous: if you want several models in one council, the official channel is MoA's slots, not subagents. The good news is that the context-side cost is milder than you might fear. The docs state that MoA is built so "the main conversation's prompt cache is never broken", and conclude that "Its only real cost is the extra reference calls per iteration".^[1] For anyone who has to turn that into actual money, I set out the arithmetic in Hermes #9 Models & Cost.

8. A Visible Panel, and What Not to Install

If what you want is to watch several agents talk rather than have several models help write one answer, Hermes Desktop already has it, under the name Bot Mode group chat. Just be clear about what it is: a panel you sit and watch, not a committee that decides for you.

• Room size and rounds — the docs state that opening chat on a group row (2–6 Bots) opens a shared room where the whole group coordinates, and that your message "triggers up to three serial rounds of member turns"; @-mentioned Bots respond, everyone responds when nobody is mentioned, each Bot replies briefly or passes, and the room settles when a full round stays silent.^[5]
• The caps that stop a room spinning — "Hard caps (10 messages per send, 3 rounds) keep rooms from spinning", and Bots pull you in with @user, which raises a "needs you" badge on the group row.^[5]
• No voting, no chair — the Bot Mode documentation describes no voting mechanism, no chair and no consensus rule, so the person who synthesises that room's output is you. That is the opposite of MoA, where the aggregator synthesises automatically.^[5]

Choosing between them is therefore easier than it sounds — if you want one answer that has passed through several perspectives, use MoA; if you want a conversation you can read to see who thought what, use a Bot Mode group chat; and if you want a verdict on one piece of work, use /review.

The outside options, before you decide

Search the internet for "hermes council" and you will find several things. All of them are third-party, and none of them lives inside Hermes itself. The box below records the status of each as of the day I checked.

My own conclusion matches what the maintainers have done throughout: if you are going to install a third-party council, install it as an MCP server you opt into, not as part of the core. The step-by-step for adding an MCP server is the next post, #5 Skills, MCP & Memory — and before you install anything at all, ask the question the maintainers asked: how many model calls does this tool make per invocation, and can you see that cost?

9. Summary

This post opened on the bad news that there is no /council command and closes on the good news that we do not need one. What readers want — more than one set of eyes on an answer before the answer reaches them — assembles out of three things that already exist, and each of them enters at a different point of the same turn: MoA before the answer is written, /review after the work product exists, and /goal at the definition of "done".

Three things I would do today. One — build a preset called council with hermes moa configure council and ask it a question you have previously got wrong. Two — pin auxiliary.review.model to a model from a different family than your main one, and run /review over the last piece of work you already shipped. Three — turn on save_traces for a day and read one of your own trace files. I promise that what the advisors say to each other will change which aggregator you pick.