One of our AI actions extracted a date from an uploaded document: 03/04. The model picked March 4. The document was written by someone in Europe, and the date was April 3. The wrong date went into a downstream workflow, a person scheduled work around it, and fixing the mess took most of a day.
The model was not broken. The input was ambiguous, and a single model resolves ambiguity by silently picking one reading and sounding confident about it. This is the failure mode that worries me. Not wrong answers. Confident wrong answers with no signal attached.
Some context. We run more than 60 AI actions in production at my current company, a US professional-services firm. Most of them call one model, get one answer, and move on. That is fine when the answer is cheap to verify or cheap to be wrong about — a draft that a person edits anyway, a label on an internal record. But some answers trigger workflows, and some end up in front of a client. After the date incident, we stopped trusting a single model on those paths.
The fix is what I now think of as a consensus primitive. The same task goes to Claude, GPT, and Gemini in parallel. Then a synthesis pass — a fourth model call — reads the three answers together with the original input and produces a final answer plus a divergence assessment. If the three agree in substance, the answer proceeds. If they diverge, the item does not execute. It routes to a human review queue with all three answers attached, so the reviewer sees the disagreement instead of one confident guess.
The reason this works is boring: different vendors fail differently. Claude, GPT, and Gemini are trained on different data and tuned in different ways. When you sample the same model twice, the errors are correlated — you are drawing twice from one distribution, so two Claude calls that agree tell you much less than a Claude call and a Gemini call that agree. Agreement across vendors is actual evidence. Same idea as spreading a portfolio across uncorrelated assets instead of buying one stock three times.
The synthesis pass is not voting
The obvious way to combine three answers is majority voting, and it does not work for most real tasks. Voting assumes answers are comparable tokens. In practice the answers are free text. Two models can say the same thing in different words. Three models can each be partially right — one gets the date, another gets the name, the third gets both but hedges. A vote counter sees three different strings and calls it total disagreement.
So the synthesis pass is a model call, not a comparator. It receives the original input and all three answers. Its job is to reconcile: where do the answers agree in substance, where do they contradict, and is the contradiction about facts or about wording. It outputs a merged answer and a structured divergence flag.
The most important design decision: the synthesizer is allowed to say "these disagree and I cannot tell which is right." That output is a success, not an error. Early on I had to fight my own instinct here. The temptation is to make the synthesizer always produce a clean final answer, because a clean answer feels like the system working. It is the opposite. A system that hides disagreement is just a slower single model.
Months after the date incident, the same kind of input came through the consensus path. GPT read the date one way, Gemini the other, Claude flagged it as ambiguous. The item landed in review, a person asked the sender, done. Total cost of the ambiguity: one short email. That was the moment I stopped doubting the design. The input was genuinely ambiguous, and this time the ambiguity was visible instead of hidden.
What diverges most in practice, from watching this run for a long time:
- Ambiguous formats: dates, decimal separators, name order, "next Friday".
- Negation and exceptions: "everyone except", "unless", "no longer applies".
- Documents that contradict themselves — a number in the body that disagrees with a table.
- Judgment calls that look like extraction: "what is the priority of this request".
Clean extraction from clean input almost never diverges. That turned out to be useful on its own: divergence rate per task type became a data-quality metric. When a task type starts diverging a lot, the problem is usually upstream in the inputs, not in the models. We fixed two intake forms because consensus kept flagging the same fields.
The cost objection, with numbers
Everyone's first reaction is the cost. Three calls plus a synthesis pass is roughly 4x a single call. Two answers to that.
First, you do not run consensus everywhere. We run it only on paths where a mistake is expensive — a small fraction of total call volume. The bulk of the 60+ actions still use one model, because their failure cost is a person clicking "edit" on a draft.
Second, do the real math instead of reacting to the multiplier. A consensus run on a typical extraction task costs single-digit cents. A wrong answer that reaches a person costs, at minimum, the time to notice it and fix it — easily half an hour of a professional's time, often much more, plus the trust it costs you. If the extra model calls cost five cents and one prevented error saves a hundred dollars of time, consensus breaks even if it catches one error per two thousand runs. On the paths where we use it, it catches far more than that. The 4x multiplier only sounds bad until you compare it with the price of one incident.
Latency is a real cost too, and the answer to it is architecture. The three calls run in parallel, so wall-clock time is the slowest of the three plus the synthesis pass — roughly 2x a single call, not 4x. We already had multi-provider routing with circuit breakers, so a dead or degraded provider drops out automatically. If one model does not answer within a timeout, synthesis runs on two answers and records that fact. Two-vendor agreement is weaker evidence than three, but it is still evidence. What never happens is the pipeline blocking on a vendor outage. If only one answer comes back, we do not execute — the item routes to review, same as divergence.
I should be honest about the limits. The models are not fully independent. They train on overlapping data and they share failure modes on genuinely hard inputs, so all three can be confidently wrong in the same way. Studies of n-version programming found the same thing decades ago: independently written programs still share faults, because hard cases are hard for everyone. Consensus lowers the error rate a lot; it does not take it to zero. That is why destructive actions still sit behind propose/confirm/execute gates, and why everything lands in an audit trail with one-click revert. Consensus is one layer of the safety story, not all of it.
Here is the opinion I actually want to defend. Most of the "LLM reliability" work I see is prompt work. Teams spend weeks writing the tenth version of the prompt and adding more few-shot examples. That work has fast diminishing returns, and it is fragile — a prompt tuned against one model version drifts on the next release, and you tune again. Spreading the same task across vendors is a dumber idea and it works better, because it attacks the correlation instead of trying to perfect one sample.
If your system has even one path where a wrong LLM answer costs real money or real trust, add a second vendor on that path before you write the eleventh version of your prompt. With a provider abstraction already in place it is an afternoon of work. Without one it is maybe a week, and you needed the abstraction anyway. Either way it costs less than the incident it prevents.
Sources and further reading
Yilun Du and colleagues, Improving Factuality and Reasoning in Language Models through Multiagent Debate studies debate between model instances on evaluated tasks. It motivates testing multiple perspectives, but agreement is not proof of truth or independent evidence. The findings do not verify the specific system results in this article.