Vote to Decide

Aggregate many answers

In the last orchestrator lesson you fanned different subtasks out to workers and combined the distinct results. Here you fan the same question out to several agents — and now their outputs can conflict. A single agent can be confidently wrong: it hallucinates a "yes," and because you only asked once, you have no way to know. Sampling is noisy; betting the whole decision on one draw is the gamble.

The fix is ensembling: ask the same question to several agents (or the same agent several times at nonzero temperature) and combine their answers instead of trusting one. The simplest combiner is a majority vote — whichever answer the most agents gave wins. The intuition is statistical: if each agent is right more often than not and their errors are roughly independent, the majority is right far more often than any single member. Disagreement isn't noise to hide; it's the signal you aggregate.

Walk the build's case. Five agents answer a yes/no question: ["no", "yes", "yes", "no", "yes"]. You tally as you go — no seen first, then yes — ending no: 2, yes: 3, so the winner is yes (3/5). Note the tie-break: had it come back 2–2, you'd keep the option seen first, which is why you track first-seen order alongside the counts instead of trusting a map's iteration order. And you print the full tally, not just the winner — the breakdown is your evidence and your confidence signal (3/5 is a shakier call than 5/5).

Ensembling is the cheapest robustness you can buy: a few extra calls turn a fragile single guess into a decision that degrades gracefully. The cost is real (N× the compute), so you spend it where being wrong is expensive.