Thirty agents, one branch name
Parallel agents look like a safety net. Published research suggests they are closer to a single point of failure wearing a costume.
In a lab experiment published in August, 18 of 30 independently running agents created a git branch with exactly the same name. Nobody coordinated. They did not need to.
The quiet number in a loud paper
The research got attention for its dramatic findings: agents with conflicting instructions sabotaging each other, other groups negotiating truces or coordinating to keep prices high. Those make the better headline. The number that should change how you build is the boring one: 18 of 30 agents picked an identical branch name out of an effectively unbounded space of possible names.
Same model, same context, same scaffolding, same answer. That is not a bug in the setup. That is what low variance looks like when you finally measure it.
Redundancy needs variance
Most parallel-agent designs borrow their intuition from hardware. Two power supplies are safer than one because they fail for unrelated reasons. Three sensors outvote a broken one because the broken one is broken alone.
Agents cloned from the same model do not have unrelated reasons. They share weights, training, prompt, and usually the same context window. So when one of them is wrong, the others are wrong in the same direction, at the same moment, for the same reason. A majority vote among identically configured instances is not a vote. It is one opinion, counted several times, presented as agreement.
Five instances of the same model are not a safety net. They are one judgement call with five times the blast radius.
Throughput is not assurance
The distinction that survives contact with real work is what the parallelism is supposed to buy.
- **Throughput.** Five workers pulling five different sources, five files transformed at once, five test suites running side by side. Each has its own input and its own output. Uniformity here costs nothing. You are buying wall-clock time, and clones are fine.
- **Assurance.** A reviewer checking a generated change, a verifier confirming a claim, a second pass deciding whether the first pass was right. Here you are buying an independent look, and a clone cannot sell you one.
The failure mode is quiet because it looks like diligence. A pipeline with a generator and three verifiers reads as careful. If all four run on the same model with the same framing, it is a generator with three witnesses who were in the room when the story was invented.
Building the variance back in
Variance does not appear on its own; it has to be paid for. The cheap versions, roughly in order of effort:
- **Different starting evidence.** Point the verifier at the raw source, not at the summary the generator produced. Most correlated errors enter during summarization.
- **Different role, not different wording.** Give each pass a distinct job (reproduce it, refute it, check it against policy) rather than the same task in different words. Rephrasing a prompt does not decorrelate a model.
- **Different model.** The bluntest instrument and often the only one that works for the final gate.
- **One careful single pass.** Sometimes the honest answer. A group of clones is not obviously better than one attentive run, and it costs several times as much.
The collision surface nobody budgets for
The branch-name result has a second implication that has nothing to do with judgement. Identically configured agents do not just make the same decisions. They reach for the same resources at the same instant. Branch names, temp file paths, lock files, retry windows, the exact minute a scheduled job fires.
That is a class of incident where nobody did anything wrong and the system still falls over. The fix is unglamorous and takes an afternoon: derive names from something unique per run, add jitter to schedules that were all set to the top of the hour, and check whether your growing fleet of scheduled jobs currently fires in a single synchronized burst. Mine did. Uniform configuration was the convenience that created it.
Ask of every parallel step whether it is buying throughput or assurance. Only the second one needs diversity, and diversity is a design decision, not a side effect of running more copies.

