TL;DR
When several LLM agents discuss a task and converge on a shared answer, the big failures happen after the first mistake. Most often, the agents fail to fix what they've already noticed. Nearly every discussion makes a mistake, even the successful ones. The difference is that good teams climb out of the error, while bad ones get stuck in the wrong framing and won't budge, even after someone shows them the correction. Another common failure is premature agreement: the agents agree before anyone has checked the facts.
What goes wrong in practice. In round two, the agents read each other's answers for the first time. This is where individual mistakes turn into group mistakes: a model sees that the others think differently and abandons its correct answer. A correct minority opinion gets snuffed out more often than amplified, and the effect is stronger in bigger groups. The reason is simple: a model tends to conform to whatever text is already sitting in its context. Repetition looks like confirmation, even though nobody verified anything.
What helps and what doesn't. Access to evidence helps the most: search and tools sharply cut the failure rate. More agents (going from three to seven), explicit roles and hierarchy don't improve the overall result; they only change the shape of the failures. The practical takeaway: invest in fact-checking, in handling disagreement and in verifying corrections before the final answer, not in headcount.
Want this for your own case? Apply this study to your task: AI adapts its method to what you are working on and writes the prompt.
Method Blueprint
The paper doesn't offer a ready-made technique. It's a diagnosis plus a set of recommendations. The blueprint below shows how to apply them.
STEP 1: Round 1 — each agent answers independently, without seeing the others
→ answer + evidence + confidence
STEP 2: Round 2 — exchange ONLY evidence, not verdicts
→ who disagrees with what, and what backs it up
STEP 3: Minority rule — a dissenting answer is not erased
until a fact refutes it
→ registry “answer → who supports it → what confirms it”
STEP 4: Recovery check before the final answer
→ list of spotted errors and their status: fixed / not fixed
STEP 5: Final — only if there are no open conflicts and no “unknowns”
→ verdict + what remains unconfirmed
You can bake all of this into a single prompt or an orchestrator instruction. Or split it across separate chats.
Example
Task: You're an analyst at a venture fund. A startup out of Austin sends over its pitch deck. It says: “The US prepared-meal delivery market will triple by 2028.” You need to check that number before you take it to the investment committee. You spin up three checkers (three chats or three subagents with search).
Prompt (to the orchestrator):
You are the coordinator for verifying a claim. The claim from a pitch deck:
“The US prepared-meal delivery market will grow 3x
by 2028.”
<Protocol>
Round 1. Three checkers (A, B, C) work independently. Nobody sees
the others' answers. Each one outputs: a verdict (true / false / can't
verify), sources with links, confidence 0–100.
Round 2. The checkers receive not each other's verdicts, but only each
other's sources and arguments. Each one must:
- name which piece of a colleague's evidence they checked themselves;
- flag which claims were left without a source;
- change their verdict only if a new fact appeared, not because
the others think differently.
Minority rule. If one checker's verdict differs from the others',
it stays in the registry until it is refuted by a specific
fact. “The majority thinks so” is not a refutation.
Pre-final check. List every error and correction raised
during the discussion. For each one, state whether the final claim was
fixed or the correction was ignored.
Exit. Issue the final answer only if there is no open conflict between
the checkers and no “can't verify” item disguised as
agreement. Otherwise, output a list of open questions.
</Protocol>
Response format: verdict registry, list of corrections with status,
summary in one paragraph, unverified items as a separate list.
Result: The model will produce a registry: what each checker claimed and on which sources. Then it will show which disagreements survived round two. Before the final verdict you'll see a list of spotted errors marked “fixed” or “not fixed.” If someone held a dissenting opinion, it will appear in the summary as a separate line. If the facts ran short, instead of a confident “true” you'll get a list of open questions.
Why It Works
The weakness. An LLM is bad at telling “everyone says so” apart from “this has been verified.” When colleagues' answers sit in the context, the model conforms to them: agreement looks like confirmation. If the task framing is wrong from the start, every later turn just repeats it. That's why “one more round of discussion” often cements the error instead of fixing it.
The strength. The model works well with concrete material: a source, a quote, a tool result. It's pretty good at checking a claim against that material. It can list the errors it has spotted and check them off one by one.
How this gets around the weakness. The protocol forces the discussion onto evidence, not positions. Answers are collected independently, so there's no conformity effect. The minority is written into the registry and can't be quietly erased. The pre-final check spotlights errors that were raised but never fixed. That's the single most common cause of failure in the paper.
Control levers: - Number of rounds → for simple facts, one independent round plus a check is enough; extra rounds only strengthen the shared anchor. - Number of agents → don't scale up for quality: going from three to seven gave no significant gain, but the minority got suppressed harder. - Access to sources → the strongest lever. Give them search, files, links. Without evidence, the discussion turns into a vote of opinions. - Team composition → if all the agents run on the same model, they share blind spots. The paper shows that homogeneous teams fail to recover after an error more often. Use a different model for one of the checkers. - Roles → don't waste effort on flashy personas. In the paper, explicit roles had no noticeable effect.
Prompt Template
This bundles the paper's recommendations into a single instruction. The authors didn't test the template itself. What's grounded in the paper is only the logic behind it: evidence, the minority, and the pre-final check.
You are the verification coordinator for: {question_or_claim}.
<Participants>
Checkers: {num_checkers} (A, B, C...). Sources that may
be used: {available_sources}.
</Participants>
<Protocol>
Round 1 (independent). Each checker answers without seeing the others:
- verdict: {verdict_options}
- evidence: a source or a calculation for every claim
- confidence: 0–100
Round 2 (evidence exchange). Checkers see only each other's
evidence and arguments. Each one must:
- independently verify at least one piece of someone else's evidence
- mark claims without a source as “unconfirmed”
- change the verdict only given a new fact, not because of how many agree
Minority registry. If a verdict differs from the majority, it stays
in the registry until it is refuted by a specific fact.
Recovery check. Before the final answer, list every error and correction
that was raised. For each one: is it fixed in the final answer?
If not — go back to round 2 for that item.
Exit condition. Final answer only if: there is no open conflict between
the checkers AND no “unknown” items passed off as agreement.
Maximum {max_rounds} rounds. If the condition isn't met — output
a list of open questions instead of a verdict.
</Protocol>
<Output>
1. Registry of verdicts and evidence
2. List of corrections with status
3. Summary
4. What remains unverified
</Output>
What to fill in: {question_or_claim} — what you're checking. {available_sources} — search, your documents, APIs. {verdict_options} — for example, “true / false / can't verify.” {max_rounds} — usually 2–3.
🚀 Quick start — paste this into the chat:
Here's a template for a multi-agent verification protocol. Adapt it to my task: [your task].
Ask me questions to fill in the fields.
[paste the template above]
The LLM will ask what exactly to check, which sources are available and how many checkers you need. It needs this so the protocol runs on evidence: without sources, trading facts turns into trading opinions. It will take the structure from the template and assemble a ready-to-use instruction for your task.
Limitations
⚠️ Weaker models: almost all the experiments ran on small and mid-size open models. The paper doesn't show how this plays out on the strongest current models.
⚠️ The recommendations aren't battle-tested: there's an intervention experiment only for evidence access. The minority rule and the pre-final check are conclusions drawn from failure analysis. The authors haven't proven that they actually eliminate those failures.
⚠️ Evidence access isn't a silver bullet: with tools, the share of consensus errors among failed discussions actually goes up. What helps is that the total number of failures drops. But ignoring tool results remains a common error.
⚠️ Round-based discussions only: the findings apply to the “agents answer, read each other, answer again” setup. Vertical “planner → executor” chains and single-chat use aren't directly covered by the paper.
⚠️ The error labeling was done by a model: the taxonomy was built by an LLM, and human validation covered a sample of 200 trajectories. That's enough for general conclusions, but not for precise percentages.
⚠️ The stats are over failures: the taxonomy percentages are computed among failed trajectories. They show how discussions break, not how often they break overall.
How They Studied It
The researchers collected traces of multi-agent discussions across eight datasets: medical questions, finance, code, multi-hop questions, ethics. In total they ran 7,300 tasks, and 3,543 of them ended in an error. The analysis covered 3,211 failed discussions with multiple rounds. Teams varied by number of agents, models, tool access, roles and hierarchy.
The taxonomy was built like this: each failed dialogue was compressed into an “evidence card,” then a model assigned labels and grouped them. The result: 6 parent categories, 24 child categories and 11 final leaves. Two-thirds of the main findings fall into two branches: recovery failures show up in 94.9% of failed trajectories, consensus failures in 83.4%. Three people independently labeled 200 cases without seeing the taxonomy. The taxonomy managed to cover 93.4% of the errors the humans spotted.
The most surprising result came from the control group. The researchers took 500 successful discussions, and 91.2% of them contained at least one error. Reasoning and tool use went wrong equally often in successful and failed cases. But “persistent wrong framing after correction” was 7.5 times more frequent in the failures, and premature consensus 3.5 times more frequent. The conclusion: a team's quality is determined by its ability to recover, not by the absence of errors.
Team design was studied on pairs of configurations where only one factor changed. Evidence access cut the failure rate from 74.6% to 36.4% on multi-hop questions. Growing the team from three to seven agents didn't help significantly. Roles showed no effect at all. Hierarchy removed answer oscillation, but not overall failure. Homogeneous teams failed to recover after an error more often: shared blind spots.
The authors also checked whether a failure can be predicted before the final answer. They trained a random forest on 304 discussions using answer dynamics (agreement, switches, confidence). It caught premature consensus and recovery failure in advance. If you don't write code, take this part as an idea: watch the dynamics, not just the outcome.
Original From the Paper
A fragment of the taxonomy (Figure 1) covering the two main parent branches. Percentages are the share of failed trajectories with that failure type.
Recovery / correction (94.9% of failed trajectories)
Persistent wrong framing after correction 17.3%
Anchor-driven recovery failure 8.0%
Ignored or weakly adopted correction 5.1%
Superficial patching without validation 2.6%
Correction drift or oscillation 1.6%
Couldn't recover after unknown 5.1%
Failed recovery after disagreement 4.3%
Failed recalculation or computational repair 3.8%
Corrective signal ignored 3.3%
Consensus / decision making (83.4%)
Premature consensus 15.1%
Social convergence without verification 7.6%
Anchor-driven lock-in 4.0%
Premature closure on uncertain or
incomplete evidence 2.5%
Unresolved conflict masked by agreement 1.0%
Oscillating consensus / answer instability 6.4%
Answer drift 5.7%
False equivalence b/w distinct answers 0.4%
Tool / evidence use
Evidence retrieval or mapping failure 5.2%
Weak, fabricated, or unsupported evidence 4.1%
Tool/evidence result ignored or not shared 2.0%
Tool/evidence output misread 0.1%
Context: this is the final taxonomy of communication failures, built from 3,211 failed discussions. You can use it as a checklist when reviewing your own agents' logs.
Adaptations and Extrapolations
💡 Adaptation for log audits: take a transcript of your agents' conversation and ask a model to label it using the paper's taxonomy. The point is to look not for “where's the error” but for “where was the error noticed and never fixed.”
Below is a log of a discussion between several agents: {log}. Label it by category: 1) persistent wrong framing after correction 2) premature consensus (agreed without verification) 3) ignored tool result 4) suppressed minority opinion 5) answer drift or oscillation For each problem found, give: the turn that proves it, the round in which it appeared, and whether there was a chance to fix it.
🔧 Technique: a dynamics-based stopping condition → protection against early agreement. Instead of “stop when everyone agrees,” write this in the orchestrator instruction: “Agreement in the very first round is a reason to verify, not to finalize. Ask the agents who agreed for a source and re-check one key fact.” This turns the premature-consensus finding into a stopping rule. The authors didn't test this wording.
🔧 Technique: restart instead of correcting. If the model clings to a wrong framing after a correction (the most common error in the taxonomy), here's a simplified workaround: open a new chat or subagent and give it only the corrected problem statement and the source data, with no debate history. This is my extrapolation from “the anchor sits in the context”; the paper didn't test this workaround.
💡 Adaptation for an agent instruction file (AGENTS.md / CLAUDE.md):
## Rules for coordinating with other agents - Don't change your conclusion just because another agent thinks otherwise. Change it only given a new fact you verified yourself. - If a tool result contradicts the shared opinion, the tool result wins. - Before sending the final answer, list the corrections from the discussion and say whether each one was taken into account. - Don't hide disagreement: put the dissenting opinion in the final answer.This carries the paper's recommendations over into an instruction. The authors didn't test them as instructions for agents.
Resources
- Paper: Understanding Communication Failures in Multi-Agent LLM Systems (the AgentInteractError taxonomy)
- Authors: Priya Pitre, Jun Hou, Yi Fang, Naren Ramakrishnan, Xuan Wang — Virginia Tech, Blacksburg, USA
- Foundational work: Cemri et al. (2026) — a general taxonomy of multi-agent system failures; Wynn et al. (2025) — abandoning correct answers after hearing others' opinions; Du et al. (2024) — Multi-Agent Debate; Kargupta et al. (2025) — TaxoAdapt, a taxonomy-construction method