Summary: When an agent is not accurate enough, the reflex is to run it three times and take the majority. It works, briefly, and then it stops working precisely where you need it most. A July 2026 measured study quantified the whole curve: what voting buys, what it costs, and the error floor it cannot cross. This is the data, and the reason the industry’s favorite reliability patch cannot produce production-grade accuracy.
What the measurements show
The measured study ran the same multi-document evaluation workload repeatedly on live models and counted both the flips and the tokens:
- Single-pass borderline flip rate: roughly 20%. Run the same evaluation twice and one case in five near the decision boundary changes verdicts.
- 3-vote majority: roughly 10% borderline error. Modeled 2-vote configurations land near 12%. Real improvement, clear plateau.
- The cost: roughly 3.3x model spend for 3 votes plus a verification pass. Measured per cycle: $1.34 single pass versus $10.63 to $15.27 for the voting configurations. Caching barely helps, because votes generate fresh output tokens every time and output is never served from cache.
Pay triple, cut borderline error in half, and stop at a floor around 10%. The floor is the story.
Why the floor exists
Voting is a noise filter. It corrects the errors that come from run-to-run randomness: sampling variance, order effects, borderline coin flips. It is mathematically incapable of correcting the other kind of error: the cases the model gets wrong for a reason. A misread exhibit, a policy nuance the prompt does not carry, a systematically ambiguous document: those vote the same wrong way three times, unanimously and confidently.
The cruel part is where the floor binds. Weak architectures get the most from voting, because they have the most noise to cancel. Strong architectures get the least: a system that is already 84% accurate pays the same 3.3x and gains a few points, because its remaining errors are systematic, not random. Voting stops paying off exactly where systems get good, and nothing in the ensemble ever reaches 99%.
What the pattern costs at volume
At production scale the ensemble tax compounds. Every case pays 2x to 3x compute; cycle time multiplies with the passes; and the residual 10% borderline error still needs a human queue behind it, so you pay redundancy and review. Our token economics analysis walks the full budget math; the short version is that voting is the most expensive way to buy the accuracy it delivers.
What actually reaches 99%+
Production-grade accuracy comes from removing variance at the source rather than averaging over it:
- Deterministic checks run as code. Threshold comparisons, reconciliation, and completeness checks do not need a model, so they contribute zero variance and zero tokens. In document workflows this covers a large share of the rules.
- Constrained, evidence-linked model calls. Where judgment is needed, the call is schema-bound and every extracted value carries a pointer to its source, so wrong values are catchable instead of votable.
- Confidence routing to humans. The genuinely ambiguous cases, the ones voting would coin-flip, go to a reviewer with the evidence attached. That is progressive autonomy doing the work redundancy cannot.
That is the architecture behind compiled execution, and it is how MightyBot sustains 99%+ decision accuracy in production regulated workflows with roughly 2% residual review, a floor no ensemble of stochastic passes can reach at any multiplier.
If you are currently paying for votes, run your own numbers in the ROI calculator: the quality-strategy controls model human review against 2-vote and 3-vote ensembles with the measured floors built in.
