There's an intuitive shortcut when you're running multiple AI models on the same question: count the votes. If Claude and GPT-5 agree and Gemini disagrees, go with the majority. Two out of three. Democracy works.
It doesn't work.
A new paper out of arXiv — "Council Mode: Mitigating Hallucination and Bias in LLMs via Multi-Agent Consensus" (April 2026) — puts concrete numbers on something that should change how you think about AI deliberation. The synthesis layer of an AI council isn't supposed to find where the models agree. It's supposed to figure out when the model that disagreed was right.
That's a harder job. And most council implementations punt on it.
The Majority Vote Problem
Here's what majority voting in an AI council actually optimizes for: shared hallucinations.
If three models were all trained on the same internet, all slightly overweight the same popular narratives, all tend to over-confirm rather than challenge — their consensus might be confidently wrong in exactly the same direction. You haven't found truth. You've found the center of mass of correlated biases.
The paper frames it precisely: AI models exhibit "systematic biases that are amplified by uneven expert activation during inference." In other words, the models don't fail randomly. They fail in patterns. And those patterns often cluster — which means majority voting can make the bias problem worse, not better.
The fix isn't to add more models. It's to design the synthesis layer differently.
What the Research Actually Proposes
The Council Mode paper proposes a three-phase pipeline:
Phase 1: Triage. Not every question needs a council. An intelligent classifier routes queries by complexity. Simple lookups go straight to a single model. Questions with genuine uncertainty, high stakes, or meaningful edge cases get escalated to the full council. This is obvious in retrospect but most multi-model tools skip it — they council everything or nothing.
Phase 2: Parallel expert generation. Multiple architecturally diverse models answer the question independently, then critique each other. The diversity isn't cosmetic — it's the mechanism. You want models that were trained differently, fine-tuned differently, optimized for different domains, so their disagreements are actually informative rather than arbitrary noise.
Phase 3: Structured consensus synthesis. This is the interesting one. The synthesis model "explicitly identifies agreement, disagreement, and unique findings before producing the final response." Not a vote. Not an average. A deliberate decision about which findings to surface and why.
The paper's key claim: the final output is "not merely a majority vote but a nuanced integration that preserves valuable minority insights while filtering out individual model hallucinations."
Preserving minority insights while filtering hallucinations. Those are two different things. Doing both simultaneously is the hard design problem — and most systems only attempt one of them.
What the Numbers Say
The results across standard benchmarks:
- 35.9% relative reduction in hallucination rates on HaluEval
- 7.8-point improvement on TruthfulQA
- 85–89% reduction in bias variance across domains
The bias variance number is the one worth sitting with. Not a small reduction. Not "somewhat better." 85–89% reduction. If you're making decisions in domains where bias matters — hiring, medical, legal, financial — that's the difference between "the AI got it wrong the same way every time" and "the council caught the pattern before it compounded."
The hallucination reduction is what headlines will focus on. The bias variance reduction is what practitioners should care about more.
Why This Is Harder Than It Looks
The synthesis layer has to make a judgment call about when the dissenting model deserves to win.
Here's a concrete version of the problem: you ask four models whether to accept a job offer. You describe the role, the salary, the team. Three models say yes. One model says no.
Do you go with the majority?
Depends entirely on why the outlier said no. If it flagged a clause buried in your description — non-compete terms that would lock you out of your industry for 18 months — then the outlier just saved you from a majority-endorsed disaster. If it said no because it misread your industry and confused something in your framing — then the outlier is noise and the majority was right.
The synthesis model's job is to tell the difference. And that requires reading the deliberation, not tallying it.
This is genuinely subtle. A naive majority-vote system would suppress the outlier in the first scenario and suppress it in the second scenario too. It can't distinguish between "this model found something the others missed" and "this model got confused." The research is showing that when you build a synthesis layer that makes this distinction explicitly — when you force it to identify the reasoning behind disagreement rather than just the disagreement itself — you recover most of the value that majority voting throws away.
How Shingikai Approaches This
The Chairman model in Shingikai's council architecture is designed exactly for this role. It doesn't get a vote. It reads the full deliberation — who said what, what was flagged, where the models diverged — and then it produces a synthesis that explicitly surfaces areas of consensus, areas of genuine disagreement, and the reasoning that resolves them.
On questions where one model flagged something the others missed, that flag shows up in the synthesis. The Chairman elevates it rather than suppressing it in an averaging process.
This is why the Chairman model selection matters as much as the panel composition. You want a model that's good at reasoning about reasoning — not just answering questions, but reading a debate and deciding when the dissenter deserves more weight than the majority.
The synthesis prompt matters more than panel size. If your synthesis layer is just concatenating answers and asking a model to "combine these," you're not building a council — you're building an expensive summarizer.
The Practical Implication
If you're building on top of multi-model APIs, or using any council-style tool, here's the question to ask: what does the synthesis layer actually do?
If the answer is "average the outputs" or "go with the majority," you're leaving most of the value on the table. You've added the cost and latency of multiple models without capturing the insight that makes deliberation worth it.
The research validates what practitioners in this space have been learning by doing: design the synthesis to interrogate disagreement rather than dissolve it. When one model is the only one that flagged a risk, or offered a non-obvious reframe — that's not noise. That might be the whole point.
Try it for yourself. Run your next hard question through a council at shingik.ai — free, no signup. See what happens when the models disagree.