Tokonomix Council

tokonomix-council-mcp

A multi-model consensus MCP server — cross-vendor proposers, an independent judge, and blind-spot/disagreement detection for high-stakes AI decisions. An open reference implementation of AI Decision Engineering — a discipline we are proposing, not yet an external standard.

Mission. Help autonomous systems make better decisions by combining independent expert reasoning instead of trusting a single model.

In 20 seconds: Important AI decisions deserve more than one opinion.

The Tokonomix ecosystem (where Council fits)

Council is one specialized component in a larger stack. Each owns exactly one responsibility, so they compose cleanly:

   Execution    →  ANS         (run a backlog to completion, unattended)
   Decision     →  Council     (independent review → grounded decision)   ◀── this repo
   Verification →  Media QC    (image / video / document output quality)
   Measurement  →  Benchmark   (intelligence tests, arena, reputation)
   Routing      →  Router      (which provider/model hosts a call)
   Memory       →  Memory      (durable context across sessions)
   Safety       →  Safety      (policy / guardrail enforcement)

Council owns one box: the decision. It does not execute, schedule, route, or remember — those live in their own components (details below).

Status — what is live right now

So you never call something that isn't there yet. Server-gated features can be off for your account/tier; when they are, the tool returns a clear "not enabled" message instead of erroring.

Council MCP exists to improve decision quality, not to chat, generate, or route. The governing idea is simple:

Consensus × Ground Truth = Decision Quality

Consensus is one mechanism for decision quality — not the whole of it. Grounding (checking a claim against the real artifact) is the strongest lever, stronger than adding more models; judge-independence and verification are mechanisms too. Several independent expert models assess the same problem in parallel and blind, an independent, cross-family judge reconciles their findings, and grounding ties the whole thing to reality — so you get one decision you can act on, with the disagreements a single model would have hidden surfaced rather than smoothed away. Consensus is a means; better decisions are the goal.

It is not a chatbot, a model, an LLM, a prompt library, a multi-model chat, a voting system, or an averaging system. It does not make any model smarter, and it does not pick a winner by majority — it changes how multiple independent models' outputs become one defensible decision.

What it honestly buys you — and what it does not. Across our own validation (see Benchmarks), the council ties the best single model on clean accuracy and beats it nowhere, and on a SWE-bench bug-detection run it showed no measurable net uplift in catch rate over re-running a single agent. So we do not claim "more accurate" or "catches more bugs" anywhere. What it does buy is variance-elimination (you stop gambling on which single model you happened to ask), a verification / agent-QA layer, judge-independence, EU data residency, and grounding. Read When consensus helps / doesn't / can hurt before you rely on it — that section is the point, not a disclaimer.

Works with Claude Code, Cursor, Cline, Continue, and Zed. One npx line to install.

Principles of Decision Engineering

The discipline Council implements rests on ten principles. An autonomous system should:

1. Verify before acting — a decision is provisional until it has been checked.
2. Preserve disagreement — the lone dissent is often the finding that mattered; never average it away.
3. Separate execution from judgement — the thing that does the work should not also be the thing that grades it.
4. Separate reasoning from verification — generating an answer and checking it are different jobs.
5. Separate confidence from correctness — a model's tone is identical whether it is right or wrong.
6. Prefer evidence over agreement — agreement measures agreement, not truth; ground the claim.
7. Expose uncertainty — surface what was not settled, don't hide it behind one confident answer.
8. Make decisions auditable — record who proposed, who judged, what it cost, on what input.
9. Remain reproducible — the same input and method should be re-runnable to the same finding.
10. Never hide failure modes — a decision tool that conceals when it fails is not a decision tool.

What Council owns — and what it explicitly does not

Council is a Decision Engineering layer. Its scope is deliberately narrow, because a clear boundary is what makes a component trustworthy to compose with.

Council owns DECISIONS ONLY:

• decision quality and decision confidence,
• independent review and reasoned consensus,
• verification of reasoning and claims,
• grounding (checking a claim against the real artifact),
• disagreement analysis,
• judge independence,
• auditability of how a decision was reached.

Council is explicitly NOT responsible for: execution, workflow, task scheduling, agent autonomy, long-term memory, provider routing, or browser automation. Those are real responsibilities — they simply live in other components.

• Need something executed (a backlog run to completion, unattended)? That is Agents Never Sleep (ANS), the execution governor. ANS is the worker/governor; Council is the verifier it can delegate a decision to. Council does not run, schedule, or remember work.

See Council in the Tokonomix ecosystem for where every adjacent responsibility lives.

Why Council exists (the short story — for a human OR an AI agent)

Why does Council exist? Because important AI decisions are made by single models that answer with total confidence and never tell you what they didn't consider. For chat that is fine; for a security review, a migration, a GDPR interpretation, or a legal clause, a confidently-wrong decision is expensive and you find out too late.

Why is one model not enough? A single model is one opinion with one blind spot. Which model is strongest is not stable — it shifts per task, per domain, per bug class. Standardise on the wrong one and you ship real defects without ever seeing a disagreement.

When does combining models help? When errors are uncorrelated: different vendors are wrong about different things, so you only need one of them to catch the timing side-channel or the missed edge case for it to surface. That decorrelation only exists across vendors — a single vendor's "panel" shares its own training data and blind spots.

When does it NOT help? On routine work (renames, formatting, lookups) and on easy tasks any strong single model already saturates. There the council only adds cost and noise — use a single model.

Why does grounding matter more than more models? Because agreement measures agreement, not truth. Ungrounded, frontier models can agree and be uniformly wrong (they share training data). Feeding the council the real artifact — the literal file, diff, spec, logs — is the lever that turns "they agreed" into "they checked it against reality." More models cannot fix a shared blind spot; grounding can.

Why does judge independence matter? Because a judge that also wrote one of the answers scores its own work and inflates agreement (LLM self-preference is real and measured). A disjoint, cross-family judge is the only honest reconciler.

Why do failure modes matter? Because consensus can be worse than a single model — lossy synthesis, correlated failures, false consensus, specialist overlap. A decision tool that hides its failure modes is not a decision tool. Honesty about when consensus does NOT work is the competitive advantage, not a caveat we bury.

Contents

1. Why Decision Engineering is becoming necessary
2. Why LLMs cannot solve this themselves
3. Design principles
4. A story: the security review
5. The problem
6. Why single-model review falls short
7. How Council works
8. Architecture
9. The consensus process
10. The judge
11. When consensus helps / doesn't / can hurt
12. Decision Engineering vs existing techniques
13. Council in the Tokonomix ecosystem
14. Practical examples
15. Installation
16. Integration & API surfaces
17. Benchmarks
18. Glossary
19. FAQ
20. Roadmap

Going deeper: this README is the field guide. The full argument — why the field exists, the design principles, the failure modes, why one model is insufficient, why consensus alone is insufficient, why grounding is necessary, and why a human stays ultimately accountable — lives in the Decision Engineering Manifesto. The README links out rather than duplicating that depth.

Why Decision Engineering is becoming necessary

Every time software took on more responsibility, a new discipline appeared to keep it trustworthy — not because engineers got worse, but because the cost of an unchecked output got higher:

The pattern is the same each time: a capability outran our ability to trust it, and we built a discipline to close the gap. LLMs have crossed that line — they no longer just generate text, they decide: which migration is safe, whether an auth path is exploitable, how a clause reads under GDPR. A decision made by one confident model, with no independent check and no record of what it didn't consider, is exactly the unchecked output every prior discipline was invented to catch. Decision Engineering is that discipline for the era where models, not only people, make the call.

Why LLMs cannot solve this themselves

The obvious objection is "models keep getting better — won't a strong enough single model just be right?" It misreads the problem. The issue is not that any given model is weak; it is structural:

A model cannot independently verify itself. Asking the same model "are you sure?" runs the same weights over the same training data and the same blind spot — it will defend its first answer with the same confidence, because the thing that produced the error is the thing you are asking to find it. Self-critique inside one model is not an independent check; it is the same mind marking its own exam. This is true of GPT, of Claude, of Gemini, of whatever ships next — not a comment on any of them being weak.

Independence has to come from outside the model:

• A different vendor, because correlated training data means a single vendor's "panel" shares the same blind spots — its own agreement is not corroboration.
• A different role — a judge that did not write the answer, so it isn't scoring its own work (LLM self-preference is real and measured).
• External ground truth — the literal file, diff, spec, or logs, because a model cannot conjure a fact it never had, and agreement on a shared wrong prior is still wrong.

That is the whole argument for why Decision Engineering is a layer above models rather than a better model: the independence and the grounding that make a decision trustworthy are precisely the things one model cannot supply for itself.

Design principles

Council's engineering follows from the principles above. Each is a constraint we hold ourselves to, not a marketing line:

• Single Responsibility — Council decides; it does not execute, schedule, route, or remember. A narrow scope is what makes a component safe to compose.
• Independence — proposers answer blind and in parallel; the judge is disjoint from them and cross-family. No model grades its own work.
• Ground Truth — claims are checked against the real artifact, not a paraphrase or a shared prior. Grounding outranks panel size.
• Evidence First — corroboration must rest on the evidence, not on models happening to agree.
• Auditability — every decision returns who proposed, who judged, and what it cost, so it can be reconstructed.
• Transparency — what was not settled is surfaced (the blind-spots section, the diff map), never hidden behind one answer.
• Reproducibility — the same input + method re-runs to the same finding; record the models and date, because the default council can change.
• Traceability — a request_id and a billing breakdown tie a stored decision back to exactly how it was produced.
• Human Accountability — Council surfaces and grounds; it does not absolve. A human (or your agent acting for one) remains ultimately responsible for acting on the decision.

A story: the security review

A team ships an authentication middleware. Before merge, an engineer pastes it into a single strong model — GPT — and asks, "any security issues?" The answer comes back clean: "No issues found, the implementation looks correct." One confident opinion, no dissent, nothing flagged. It merges. Three weeks later a token-comparison side-channel — the kind where response timing leaks whether the first byte of a secret matched — is exploited in production. The post-mortem is expensive, and the worst part is that nothing warned them: the review said "fine," so they believed it was fine.

Now replay it through Council. The same middleware fans out to several independent vendors, blind and in parallel. Three of them also say "looks fine." But Claude, reading the literal source rather than a summary, notices the comparison isn't constant-time and flags a possible timing leak. Because the proposers answered independently, that lone dissent isn't drowned out — and the independent judge, instead of papering over the split, surfaces the disagreement: "one reviewer flags a non-constant-time token comparison; the others did not address timing." The engineer sees a disagreement on a security-critical path, investigates the one finding that mattered, confirms the leak, and fixes it before merge.

That is the entire difference: not a smarter model, but a process that preserved the dissent and put it in front of a human instead of averaging it into a confident "looks fine." The bug was always catchable — it just needed one independent reviewer to see it and a design that wouldn't bury what it found.

The problem

A single LLM is a single point of failure. It answers with total confidence — and, worse, it never tells you what it didn't consider. For a chat reply that's fine. For a security review, an architecture decision, a GDPR interpretation, a database migration, or a legal clause, a confidently-wrong answer is expensive, and you find out too late.

The reflex fix — reach for a bigger model — doesn't address the failure: a bigger single model is still one opinion, with one blind spot, that still won't tell you what it missed. And which single model happens to be strong is not stable: it shifts per task, per domain, and per bug class. Standardise on the wrong one and you ship real defects without ever seeing a disagreement.

Council MCP is built for exactly the class of decision where being wrong is asymmetrically costly: code / security / architecture / legal / document / quality / media / policy review, evaluations, and benchmark testing — anywhere a single model's blind spot is expensive. Use it there; for variable renames, formatting, and simple CRUD, a single model is cheaper and entirely sufficient.

Why single-model review falls short

The value of asking more than one model comes from uncorrelated errors — different models being wrong about different things. A single model gives you none of that:

• One opinion, one blind spot. You see what that model saw; you never see what it skipped.
• Confidence is not calibration. The model's tone is identical whether it is right or wrong. There is no internal "I'm unsure here" you can read off.
• No surfaced disagreement. A single call cannot show you the thing only some reviewers would have caught — because there is only one reviewer.
• Model strength is task-dependent. On the same set of tasks, one model catches an IDOR that another returns "no issues" on, and vice-versa. There is no single model that is best everywhere, so a single-model standard guarantees a class of misses.

Asking the same vendor for a second opinion does not fix this: its own "panel" is its own models, trained on its own data, sharing its own blind spots — correlated errors dressed up as agreement. The decorrelation that makes review valuable only exists across vendors. That cross-vendor check, reconciled by a neutral judge, is the thing a single-vendor API structurally cannot give you.

This is also why "just average the answers" is wrong: averaging destroys the lone dissent, which is frequently the finding that mattered. The design problem is to preserve dissent and adjudicate it, not smooth it away.

How Council works

You call one tool; the orchestration, scoring, and reconciliation run server-side; you get one decision.

            ┌─ Claude  ─┐
your prompt ─┼─ GPT     ─┼──▶  independent