Why One LLM Gives You Groupthink, and How a Swarm of Conflicting Experts Fixes It

Ask one model to evaluate a hard decision and you get one view: usually balanced, cautious, and averaged toward the middle. That is the failure. A contested decision should be attacked from several sides, and a single model tends toward groupthink with itself. The fix is structural, not a better prompt: an orchestrator picks a handful of expert roles whose interests deliberately conflict, each analyzes the decision independently without seeing the others, and a merge step reconciles their conclusions while keeping the disagreement visible instead of averaging it away. The pattern is cheap, runs in parallel, and has been making the rounds as the "analytical swarm." It is also a near-perfect answer template for the multi-agent questions in Applied AI interviews, provided you also know when not to use it. Both halves are below.

The problem: one model averages

Models are tuned to be balanced. On "should we remove the free tier," a single pass gives you the "on one hand, on the other hand" answer, finds the safe middle, and moves on. For a summary that is a feature. For a decision it is a defect, because the information you need is exactly what the balanced answer smooths over: the sharpest case for, the sharpest case against, and the risk only one perspective can see.

Note this is a different problem from getting a wrong fact, and it has a different fix. Sampling the same prompt five times and voting (self-consistency) works when there is one right answer to converge on. A decision has no single right answer to vote toward, so voting just gives you the average five times. You do not want the variance collapsed. You want it organized.

The architecture: orchestrator, experts, merge

The swarm has three components, and each exists to protect a specific property.

The orchestrator picks the roles, per task. Given the decision, it defines three to five expert roles that will see it most differently: for a pricing change, perhaps a revenue owner, an infrastructure engineer, and a user advocate. The orchestrator does not analyze anything itself, and the roles are not hardcoded, which keeps the system general. The one requirement worth engraving: the roles must conflict, not complement. A marketer, a content manager, and a growth lead will return the same opinion three times because their interests point the same way. Money now versus trust later, speed versus quality: a conflict of interests is what cracks a decision open.

The experts run independently and in parallel. Each gets the same decision through its own lens, with an explicit bias it is told to push rather than balance, and none of them sees another's output. Parallelism here is not a speed optimization, it is the guarantee of independence: an expert that physically cannot read the others cannot conform to them. This is the same reason serious LLM-as-judge setups keep judges blind to each other, and the counterintuitive part is the prompt: you forbid the expert from being balanced. Let each one account for all sides and you get five identical cautious opinions, which is the single-model failure again, just five times the cost.

The merge reconciles without averaging. The synthesis step collects the opinions and reports four things: where the experts agree despite opposed positions (the strongest signal you have), where they directly contradict (a real trade-off someone must own), what only one of them saw, and a final verdict with the conditions under which it flips. A bad merge turns five sharp opinions into one toothless summary. A good one keeps the conflict on the page, because the conflict is the analysis.

There is one configuration detail that separates people who have run this from people who have read about it: run the experts hot and the merge cold. High temperature at the expert stage buys diverse, committed positions. Low temperature at the merge buys a sober reconciliation. One knob, two settings, opposite jobs.

The guard: a devil's advocate against fake agreement

Sometimes the experts converge not because the decision is good but because they all looked the same way out of it. That fake agreement is more dangerous than open conflict, because it reads as confidence.

The guard is one more role that runs after the experts and before the merge, with a single job: attack the consensus. If the swarm voted unanimously yes, the advocate must find the shared assumption nobody checked and the scenario where the unanimous call fails badly. Its objection goes into the merge alongside the opinions. The cost is one extra call. What it buys is structural: consensus now has to survive an attack rather than merely happen. If the budget allows one more round, a debate pass (show each expert the others' arguments and let it object or hold its line) hardens the surviving positions further, but the advocate is the step that earns its cost first.

The honest boundary: analysis, not serving

Here is where this post diverges from the enthusiasm, and where interviews get serious. Everything above describes a one-shot analysis tool: a handful of parallel calls, run before a decision, with a human reading the output. In that regime the swarm is cheap and the failure mode is mild (a worse memo).

A production serving path is the opposite regime. There, every extra hop multiplies failure surface, compounds tail latency, and adds tokens you pay on every request, which is why our question on shipping a multi-agent system over a simple pipeline drills the opposite reflex: default to the simplest system, demand evidence for every added component, and route only the queries that genuinely need more machinery. Both reflexes are correct. They belong to different regimes, and knowing which one you are standing in is precisely the judgment the system design rounds are built to detect.

Using it in the interview

When a case study asks you to evaluate a launch, a migration, or a vendor choice with an LLM in the loop, the swarm gives you an answer with visible structure: name the conflicting roles you would instantiate, state the independence rule and why parallel execution guarantees it, describe the merge as agreement-conflict-blind-spots rather than a summary, and add the devil's advocate against fake consensus. Then close with the boundary from the previous section, unprompted. That last move matters most, because the natural follow-up is "would you run this on every production query," and the candidates who say yes reveal they never priced it. The deeper preparation for that exchange is the prompter-to-system-builder shift, and the fastest way to pressure-test the whole toolkit is the must-know question set.

The one-line version: one model gives you an average, a swarm of conflicting experts gives you a decision analysis, and the merge must preserve the disagreement, because the disagreement is the information.