Multi-Agent Design Patterns — Division, Debate, Verification

Stack as many agents as you like — if they all fail the same way, you have one agent and a larger bill. The condition under which voting actually helps, written down, then the three patterns that follow from it: division of labour, debate, and adversarial verification — plus when one agent is enough.

Improving Factuality and Reasoning in Language Models through Multiagent Debate

Does adding people to the meeting make it smarter?

"Two heads are better than one" carries a hidden assumption: that the two heads think differently. Two people trained on the same material, in the same way, get stuck at the same place. Take a vote among them and all you have done is certify the mistake with more confidence.

Running several LLM agents is the engineering version of that proverb. Take one agent — the think, reach for a tool, look at the result loop covered in LLM Agents from Scratch — run several, split the roles, compare the answers. Done well, you reach a quality a single agent cannot. Done badly, the only thing that scales is the invoice.

So this article settles when adding agents pays before it looks at any pattern. In the other order you end up copying a fashionable topology and shipping a system that is slower, pricier, and exactly as accurate.

The condition, written down

Start with the simplest arrangement. Give the same problem to $n$ agents and take a majority vote. Suppose each is correct with probability $p$, and that they fail independently.

Read in words, this is the same shape as tossing $n$ slightly biased coins and asking how often heads takes the majority. $p$ is how strongly one coin leans towards heads — the accuracy of a single agent — and $n$ is how many coins you toss, the agent count.

Equation (1) says nothing more than "the probability that more than half of the $n$ agents are right." $\binom{n}{k}$ is the number of ways to pick $k$ agents out of $n$; $p^k(1-p)^{n-k}$ is the probability that those $k$ get it right and the rest do not. What matters is the direction. If $p > 0.5$, raising $n$ pushes the result towards 1. If $p < 0.5$, it pushes it towards 0. On a task where a single agent is right less than half the time, adding agents makes you reliably wrong.

And the whole equation rests on that one-line independence assumption. Let $\rho$ be the correlation between the agents' errors. Then the spread of their average behaves like this:

Put in words, adding agents only dilutes the part of the error each one makes on its own; the part they all make together survives however many you line up. The arrow on the right reads "where this ends up as the agent count grows without bound."

Here $e_i$ is each agent's error, $\sigma^2$ is how large those errors are, and $\rho$ is how strongly two agents tend to be wrong in the same direction. Equation (2) makes exactly one point: no number of agents pushes the spread below $\sigma^2\rho$. At $\rho = 1$ — everyone wrong in precisely the same way — the $1/n$ term vanishes and a hundred agents behave like one.

This is the sore spot of multi-agent design. Outputs from the same model, on the same prompt, at the same temperature, have $\rho$ close to 1, and neither voting nor debate does much for them. To make either work you have to force them apart: raise the temperature, change the angle of the prompt (look for counterexamples first, or state the conclusion first), hand them different source material, or use a different model. Diversity in sampling has been a working resource ever since self-consistency, which draws multiple reasoning paths and votes over the answers (Wang et al., 2022).

Pattern 1: Division — cutting the context into pieces

Splitting roles is a pattern about context and attention more than about accuracy. Cram "read the spec," "implement," "write tests," and "review" into one prompt and the later instructions get honoured least, while the history balloons. Give each job to a separate agent and hand each one only the material its own job needs.

There are two shapes. A pipeline is serial — survey, design, implement, verify — where each output feeds the next. It is easy to trace when something breaks, but an upstream error flows downstream untouched. A fan-out hands independent small jobs (migrate ten files, review from five angles) to agents at once, so the wall-clock time is set by the slowest single agent.

Division works under one condition: the split jobs have to stand up without knowing each other's work in progress. Force a split on work that needs shared state and one side proceeds on a stale assumption, then nothing reconciles at integration time. If parallel agents write files, give each its own working directory — a separate git worktree, say. Fix the handoff format too: prose handoffs make the downstream parser flaky, so pin the shape with a JSON schema (Structured Output and Constrained Decoding).

Pattern 2: Debate — read each other, then rewrite

Multiagent debate has $n$ agents answer independently, then shows every answer to everyone and asks them to write again. Repeat for a few rounds and take what converges. Du et al. report that this procedure moves answers towards better-supported ones on mathematical and factual tasks compared with single-shot generation (Du et al., 2023). What separates it from plain voting is that the other agents' reasons enter the input: if one agent spelled out a condition another missed, the rewrite can absorb it.

Debate also has a failure mode of its own: sycophancy. Told "I think your answer is wrong," an LLM tends to retract a correct answer. When the majority is wrong and everyone drifts along, debate becomes an error amplifier. Three habits keep it in check:

• Round one runs without showing anyone else's answer (this protects the independent first draft)
• Ask explicitly for "rebut with evidence, or retract with evidence" rather than "reach agreement"
• Do not let the debaters make the final call — hand it to a separate judge who picks on the quality of the reasoning

A judge also lets you tune debater strength and judge strength separately. Khan et al. showed that making the debaters stronger helps a judge pick the correct side even on questions the judge cannot solve alone (Khan et al., 2024). The asymmetry that judging is easier than generating is what the whole pattern stands on.

Pattern 3: Adversarial verification — separate who passes from who fails

The third pattern splits the writer from the breaker. Do not ask the verifier whether the answer is good; ask it to produce one concrete input on which this answer fails. Vague evaluations come back as "looks fine to me," which filters nothing.

The effect is a plain conditional probability. Let $p$ be the generator's accuracy, $r$ the probability the verifier correctly rejects a wrong answer (its recall), and $f$ the probability it wrongly rejects a correct one.

Stated in words, of everything the verifier waved through, the share that is genuinely right equals "right answers that passed" divided by "right answers that passed plus wrong answers that slipped by." The vertical bar on the left reads "given that."

The numerator is "correct and passed"; the second term of the denominator is "wrong and let through." What equation (3) tells you is that $r$ is the lever. A verifier that catches half the bad answers ($r=0.5$) only halves the leak-through term, and the quality of what passes barely moves. A verifier with large $f$ throws away good answers and triggers regeneration — that shows up on the bill, not in the accuracy.

The pattern is strongest where verification closes mechanically: compile and test for code, execution for SQL, schema validation for JSON. There $r$ is effectively high and no model call is needed at all. Run automatic checks first, then send only the leftover judgement calls to an LLM verifier. Spending more compute on a single agent's thinking (Test-Time Scaling) and spending it on agents checking each other are two members of the same family: extra computation bought after generation.

Smartness is not the only thing that grows

Leave cost until last and you will redo the design. One run of a debate reads roughly agents × rounds × total output per agent tokens. When everyone reads everyone, the read volume per round grows with the square of the agent count.

Latency behaves the same way. A pipeline costs the sum of its stages, a fan-out the maximum, and a debate adds one more sum per round. Put a three-round debate behind an interactive product and users will feel it.

The smallest version in code

All three patterns fit inside this skeleton.

def solve(task, n=3, max_rounds=2):
    drafts = [propose(task, temperature=0.9, seed=i) for i in range(n)]  # write independently
    for _ in range(max_rounds):
        reports = [critique(task, d) for d in drafts]      # the breaker; ok means no counterexample
        if all(r.ok for r in reports):
            break
        drafts = [d if r.ok else revise(d, r.evidence)     # rewrite only what was faulted
                  for d, r in zip(drafts, reports)]
    return judge(task, drafts)                             # a separate judge picks on reasoning

seed and temperature are the machinery for lowering $\rho$ from equation (2), critique is the $r$ of equation (3), and max_rounds is the budget ceiling. An implementation that does not surface those three leaves you with no dial to turn later.

When one agent is enough

More often than not, this is the right answer.

• Single-shot accuracy is already high. Above $p = 0.9$ there is less than a tenth left for voting to win; the same budget spent on the prompt and the source material goes further
• Verification closes automatically. Retrying one agent until the tests pass is cheaper and more certain than debate
• The task does not decompose. Work that requires seeing the whole context at once returns locally optimal fragments when you split it
• Latency is a requirement. Behind an interactive UI, every extra round is wait time
• Errors are correlated. Same model, same prompt, run in parallel: $\rho$ is near 1 and the agent count only moves the invoice

The starting point is always one agent, its tools, and a retry. Measure that baseline, then look at the breakdown of its failures before deciding. Failures of omission call for division; failures of conviction call for debate; plausible fabrications call for verification. Adding agents before you can make that mapping is prescribing more medication without a diagnosis.

How this plays out in practice

The decision shows up for the backend engineer on an LLM product handling complaints about answer quality, for the evaluation lead asked whether more agents would raise the score, and for whoever operates an internal agent tool and has to explain its bill.

The knobs are few: temperature / top_p and prompt variants to manufacture diversity, n for the agent count, max_rounds for debate, a token budget and timeout to cut things off, concurrency, the model behind the judge, the JSON schema for handoffs, and the retry count. LangGraph, AutoGen, CrewAI, and the vendor agent SDKs all provide the wiring and state management. Observability is not optional: with Langfuse, OpenTelemetry, or similar, keep one trace per request and one span per agent, or you will never learn which agent went wrong.

The traps worth knowing. First, parallel calls to the same model with the same prompt are not a vote (equation 2). Second, sycophancy in debate erases a correct minority. Third, write collisions between parallel agents — point them at one working directory and one edit silently overwrites another. Fourth, no termination condition: "debate until you agree" does not stop when they do not agree, so impose a round cap and a token budget from the outside. Fifth, a verifier with false negatives: one that only ever answers "no issues found" has $r \approx 0$ and adds nothing but cost. The fix is to make verification a concrete task — produce one counterexample, actually run the tests.

The question that comes up in design reviews is: "we added agents and accuracy did not move — why?" Equations (2) and (3) carry the answer. Are the errors correlated (is diversity actually engineered in)? Is the verifier's recall high enough (how big is the leak-through term)? Is single-shot accuracy above 0.5 at all? A topology that grew its agent count without checking those three behaves like one agent, only slower and more expensive.

Summary

• Voting helps only when agents are right more than half the time and wrong independently; the correlation $\rho$ sets the floor (equations 1 and 2)
• Division is a pattern about context, not accuracy — split only work that does not need the others' work in progress
• Debate puts other agents' reasons into the input; keep round one independent and give the final call to a separate judge
• Adversarial verification makes refutation the job; its value is set by the verifier's recall $r$, and mechanical checks win whenever they apply (equation 3)
• Before adding agents, measure the single-agent baseline and the breakdown of its failures: omission → division, conviction → debate, fabrication → verification