Skip to content

Voting / Consensus

The Voting / Consensus pattern runs several agents on the same task in parallel, then aggregates their independent answers into one result. It trades extra inference cost for reliability: instead of trusting a single model call, you sample many and let a strategy decide the winner.

This is the classic remedy for high-variance tasks — classification, extraction, judgement calls — where any one sample might be wrong but the majority is usually right.

flowchart TB
    Task(["Task"]) --> V1["Voter A"]
    Task --> V2["Voter B"]
    Task --> V3["Voter C"]
    V1 --> Agg{"Aggregate<br/>strategy"}
    V2 --> Agg
    V3 --> Agg
    Agg --> Consensus(["Consensus"])
  1. Fan out: every agent in voter_agent_ids runs the task in parallel, each writing its answer to vote_key.
  2. Collect: the node gathers each voter’s payload (votes are compared by a canonical, order-independent serialization, so structurally-equal answers count as equal).
  3. Aggregate: the chosen strategy reduces the votes to a single consensus.
  4. Write: the result is written back to memory for downstream nodes.
StrategyHow the winner is chosen
majority_vote (default)The answer returned by the most voters wins.
weighted_voteVotes are summed using per-agent weights; highest total wins.
llm_judgeA judge_agent_id reviews all votes and decides the consensus.

The voting node type requires a voting_config block listing the voters and the aggregation strategy.

{
id: 'classify',
type: 'voting',
read_keys: ['ticket_text'],
write_keys: ['classify_consensus', 'classify_votes'],
voting_config: {
voter_agent_ids: [CLASSIFIER_A, CLASSIFIER_B, CLASSIFIER_C],
strategy: 'majority_vote',
vote_key: 'category',
quorum: 2,
},
}

For a weighted_vote, supply weights keyed by agent ID; for llm_judge, supply a judge_agent_id:

voting_config: {
voter_agent_ids: [JUNIOR, SENIOR, STAFF],
strategy: 'weighted_vote',
vote_key: 'verdict',
weights: { [JUNIOR]: 1, [SENIOR]: 2, [STAFF]: 3 },
}

The node writes two keys into WorkflowState.memory:

  • {nodeId}_consensus — the aggregated answer.
  • {nodeId}_votes — the full array of individual votes (for auditing and traceability).

Both must be declared in the node’s write_keys.

  • High-stakes classification or extraction where a single sample is too risky.
  • LLM-as-judge disagreements — let several judges vote rather than trusting one.
  • Reducing variance on tasks where the same prompt yields different answers across runs.

For iteratively improving a single answer rather than sampling many, reach for Evolution or Self-Annealing instead. To check an answer against a standard rather than vote on it, see Verifier.