Multi-Agent Debate for Higher Quality Outputs

Key facts, with sources

• Anthropic reported that a multi-agent research system using an Opus lead agent with Sonnet subagents outperformed a single-agent Opus baseline by 90.2 percent on its internal research eval. (ByteByteGo)
• Anthropic's multi-agent research system used about 15x more tokens than a normal chat interaction, and token usage alone explained roughly 80 percent of performance variance. (The AI Engineer)
• The MAST research taxonomy identified 14 distinct failure modes across 7 popular multi-agent frameworks including AutoGen, ChatDev, and CrewAI, grouped into system design flaws, inter-agent misalignment, and task verification failures. (arXiv)
• Salesforce research found organizations run an average of 12 AI agents and projects multi-agent adoption to surge 67 percent within two years as enterprises move toward orchestration. (Salesforce)
• Multi-agent orchestration with three or more agents represents about 22 percent of enterprise agent deployments in 2026, projected to reach roughly 45 to 50 percent by 2027. (OnAbout AI)

The mechanics of a useful debate

A debate has three phases. First, independent proposals: each agent answers the question without seeing the others. This independence is the entire point — if agent B reads agent A's answer before forming its own, you get anchoring instead of diversity, and the debate degenerates into polishing one idea. Second, critique: each agent sees the rival answers and must attack them concretely, then optionally revise its own position. Third, judgment: a separate agent reads the final positions and synthesizes an answer.

I keep the phases as separate LLM calls with explicit prompts rather than one long shared transcript. Separate calls preserve independence where it matters, let me run proposals in parallel, and make each phase individually loggable and testable.

Where debate moves quality — and where it burns tokens

Debate pays off on tasks with a reasoning chain that can contain hidden errors: evaluating an architecture tradeoff, reviewing a migration plan for risks, deciding how to handle a nasty edge case, stress-testing an estimate. Critique is good at finding the step where the logic quietly breaks.

It does not help with factual recall — if the model does not know something, three copies of it share the same blind spot and will confidently agree on the same wrong fact. It also tends to hurt creative work, where debate sands off the interesting edges and converges on something safe and bland. And for simple extraction or classification, it is pure waste; a validation gate is cheaper and more effective. The pattern amplifies reasoning, not knowledge.

A compact implementation

This version uses two debaters with deliberately opposed stances and a judge that must state which critique points it accepted. Opposed stances matter: two agents with identical prompts drift toward agreement because models are trained to be agreeable. Giving each a bias to defend keeps the disagreement productive.

Everything runs with plain SDK calls — no framework required. In production I run the proposal phase concurrently and log each phase's output separately so I can see exactly where the final answer came from.

import anthropic

MODEL = "claude-sonnet-latest"  # replace with the latest Claude model id
client = anthropic.Anthropic()

def ask(system: str, prompt: str) -> str:
    resp = client.messages.create(
        model=MODEL,
        max_tokens=1500,
        system=system,
        messages=[{"role": "user", "content": prompt}],
    )
    return resp.content[0].text

def debate(question: str) -> str:
    stances = [
        "You favor simple, conservative solutions. Argue for your answer.",
        "You favor thorough, defensive solutions. Argue for your answer.",
    ]
    answers = [ask(s, question) for s in stances]

    revised = []
    for i, stance in enumerate(stances):
        rival = answers[1 - i]
        revised.append(ask(
            stance,
            f"Question: {question}\n\nYour answer:\n{answers[i]}\n\n"
            f"Opposing answer:\n{rival}\n\n"
            "Identify at least one concrete flaw in the opposing answer, "
            "then revise your own answer if warranted.",
        ))

    return ask(
        "You are the judge. Synthesize the strongest final answer. "
        "State explicitly which critique points you accepted and why.",
        f"Question: {question}\n\nPosition A:\n{revised[0]}\n\nPosition B:\n{revised[1]}",
    )

The judge is the highest-leverage prompt

Most of the quality gain lives in the judge, and most implementations under-invest in it. A judge prompted to 'pick the better answer' behaves like a coin flip with extra steps. A judge prompted to extract the strongest points from each position, list which critiques it accepted or rejected, and then compose a synthesis produces something genuinely better than either debater's answer.

I also split the budget unevenly: debaters can run on a cheaper, faster model because their job is generating diverse positions and attacks, but the judge gets the strongest model available. Synthesis under conflicting inputs is the hardest reasoning step in the whole pattern, and skimping there throws away everything the debate bought you.

Guarding against sycophantic collapse

The failure mode that ruins debates is premature agreement: models are tuned to be cooperative, so by the critique round both agents often declare the other's answer excellent and merge into mush. I counter this three ways. Opposed personas, as in the code above. A hard requirement that every critique name at least one concrete flaw — a rule the prompt states and my validation checks. And capping debate at one or two critique rounds, because in my experience the first round captures most of the gain and later rounds mostly generate polite convergence.

On cost: a two-debater, one-round debate is typically around five model calls with substantial context in each. I gate it behind a simple heuristic — high-stakes output types get debate, everything else gets a single pass with validation.

When to hire senior help

Multi-agent orchestration is one of the least commoditized skills in AI engineering, and teams that succeed usually include someone who has debugged coordination failures in production. Get senior review before committing to an orchestrator-worker design, because architectural mistakes at this layer are expensive to unwind after launch. If your stack includes React Native + Python + AI, a senior engineer who owns the full product beats coordinating multiple juniors.

Bottom line

Dhairya Senjaliya ships AI — Multi-Agent Architectures projects worldwide — book a scoping call to discuss your specific situation.

Common pitfalls to avoid

• ✕Defaulting to multi-agent when a single agent with good tools would do, since the roughly 15x token multiplier only pays off when subtasks are genuinely parallel and high value
• ✕Letting subagents share full conversation history instead of scoped task briefs, causing context bloat, contradictory actions, and coordination failures
• ✕Shipping without a verification layer, so errors propagate through agent chains unchecked; task verification failures are one of the three MAST failure categories
• ✕Skipping per-agent trace observability, which makes it impossible to identify which agent in the chain caused a bad final output

Frequently asked questions

Sources

• ByteByteGo
• The AI Engineer
• arXiv
• Salesforce
• OnAbout AI