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 such as classification, extraction, and judgement calls, where any one sample might be wrong but the majority is usually right.

How it works

1. Fan out: every agent passed to voting() runs the task in parallel, each writing its answer to voteKey.
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.

Strategies

Strategy	How the winner is chosen
majority_vote (default)	The answer returned by the most voters wins.
weighted_vote	Votes are summed using per-agent weights; highest total wins.
llm_judge	A judgeAgentId reviews all votes and decides the consensus.

Implementation example

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

voting([classifierA, classifierB, classifierC], {
  id: 'classify',
  reads: ['ticket_text'],
  strategy: 'majority_vote',
  voteKey: 'category',
  quorum: 2,
})

For a weighted_vote, supply weights keyed by agent id; for llm_judge, supply a judge:

voting([junior, senior, staff], {
  id: 'review',
  strategy: 'weighted_vote',
  voteKey: 'verdict',
  weights: { junior: 1, senior: 2, staff: 3 },
})

Note

Each voter is an independent agent run. A memoryQuery declared on the voting node propagates to every voter, so they all see the same retrieved memory. Use taskTimeoutMs to guard against a single hung voter stalling the round.

Outputs

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 are implied write grants, so neither needs to be declared in the node’s writeKeys.

When to use it

• 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.