When Three AI Agents Agree—and Are Still Wrong

The result looked reassuring.

Three agents had independently analysed the same insurance claim.

All three reached the same conclusion.

The claims worker said:

The customer is eligible for the full reimbursement.

The policy worker agreed.

The review agent approved the explanation.

Three agents.

Three matching conclusions.

Confidence looked high.

The answer was wrong.

All three agents had used the same outdated policy document.

Nothing was wrong with the voting logic.

Nothing was wrong with the reviewer.

Nothing was wrong with the final response generation.

The problem was simpler:

The agents were not independent enough for agreement to mean anything.

This is one of the traps in multi-agent system design.

Adding more agents can create useful specialisation, isolation, and independent review.

It can also create the appearance of verification without actually adding new evidence.

Three agents repeating the same mistake do not create truth.

They create consensus.

Those are not the same thing.

Why multi-agent agreement feels trustworthy

Imagine a system with three specialist agents:

Claims worker
Policy worker
Review agent

A customer asks:

Why did I receive only €640 when I claimed €900?

The claims worker examines the claim.

The policy worker retrieves the applicable coverage rule.

The review agent verifies the explanation.

That architecture looks stronger than asking one large agent to do everything.

And often it is.

Specialisation can make:

• Instructions narrower
• Tool access easier to control
• Outputs easier to evaluate
• Responsibilities clearer
• Failures easier to isolate

But only when the agents actually contribute different information or methods.

If every agent receives the same bad evidence, the architecture can fail collectively.

The failure

Suppose the customer has policy version 2026-04.

The current policy says:

Maximum reimbursement for this category: €640

But an older training document says:

Maximum reimbursement: €900

A retrieval defect ranks the old training document first.

The policy worker receives it and concludes:

The customer should receive €900.

The claims worker is given the policy worker’s summary and checks the claim against that amount.

It concludes:

The payment is too low.

The reviewer receives both results.

They agree with each other.

It concludes:

The explanation is supported.

The coordinator finally tells the customer:

Your payment appears to be €260 too low. I recommend requesting a correction.

Every agent behaved consistently.

The system was still wrong.

Agreement can amplify an upstream error

The failure path looks like this:

Outdated evidence
    ↓
Policy worker
    ↓
Wrong policy conclusion
    ↓
Claims worker
    ↓
Consistent claim analysis
    ↓
Reviewer
    ↓
Consistent approval
    ↓
Confident wrong answer

The downstream agreement does not compensate for the original evidence failure.

It amplifies it.

This is similar to a software pipeline where several services all consume the same corrupted record.

The fact that each service processes the record correctly does not make the record correct.

Consensus is not independent verification

This distinction is essential.

Suppose three agents answer the same question.

Case A: weak consensus

All three use:

• The same model
• The same retrieved passages
• Similar prompts
• The same tool results
• The same assumptions

They vote.

Three votes for the same answer provide limited additional evidence.

Case B: stronger verification

The system uses:

• A claims worker reading structured claim state
• A policy worker retrieving the customer’s contract
• Deterministic code checking the arithmetic
• A reviewer comparing the answer with both sources

Now agreement crosses different evidence types and methods.

That is much more meaningful.

The useful question is not:

How many agents agree?

It is:

How independent are the reasons they agree?

A reviewer is not automatically an independent check

One common pattern is:

Worker → Reviewer

The reviewer is supposed to catch the worker’s mistakes.

But consider what the reviewer receives:

Worker conclusion:
The customer should receive €900.

Evidence:
TRAINING-POLICY-2025

If the reviewer uses the same evidence and is not asked to verify its authority or freshness, it may correctly confirm that the conclusion matches the source.

The reviewer has checked consistency.

It has not checked truth.

That is an important difference.

A reviewer may need to answer several separate questions:

1. Does the conclusion follow from the evidence?
2. Is the evidence authoritative?
3. Is it current?
4. Does it apply to this customer?
5. Is required evidence missing?
6. Does another source conflict with it?

Without those checks, the reviewer may simply make the failure look more legitimate.

Test disagreement deliberately

Teams often optimise a multi-agent workflow around the happy path:

Worker A succeeds
Worker B succeeds
Reviewer approves
Coordinator responds

But some of the most valuable tests force the agents to disagree.

For example:

Claims worker:
approved_amount = €640

Policy worker:
maximum_amount = €900

Payment worker:
payment = €640

What should happen?

A weak coordinator may attempt to reconcile the conflict itself and produce:

The claim was approved for €640 because some coverage restrictions apply.

That sounds plausible.

But no evidence explains the discrepancy.

A safer result is:

conflict_detected

followed by more evidence gathering or escalation.

Disagreement should be a valid system state.

It should not be treated as a failure of the architecture.

Sometimes disagreement is the evidence that prevents a wrong answer.

Give workers structured outputs

Unstructured prose makes conflicts harder to detect.

Suppose one worker says:

The claim looks fully approved.

Another says:

The payment was processed correctly.

A reviewer has to infer whether those statements conflict.

Structured results make the comparison easier:

{
  "claimDecision": "partially_approved",
  "approvedAmount": 640,
  "evidence": "claim-api:CL-8211:v18"
}

Policy worker:

{
  "coverageLimit": 640,
  "policyVersion": "2026-04",
  "evidence": "POLICY-2026-04:section-8.2"
}

Payment worker:

{
  "paidAmount": 640,
  "paymentStatus": "scheduled",
  "evidence": "payment-api:PAY-9912"
}

Now the coordinator can compare explicit facts instead of comparing persuasive prose.

Test evidence provenance

Every important worker result should tell you where it came from.

At minimum, capture:

• Source
• Version
• Timestamp where relevant
• Entity
• Tool or retrieval call
• Worker
• Task ID

For example:

policyVersion: 2026-04
source: POLICY-HOME-2026-04
retrievalId: RET-441
worker: policy-worker-2
task: TASK-19

Without provenance, a reviewer may see two matching statements and have no way to know that both came from the same questionable document.

Provenance lets you ask:

Are these two independent pieces of evidence, or the same evidence repeated twice?

Watch for evidence laundering

A subtle multi-agent failure occurs when evidence loses its origin as it passes through agents.

For example:

Policy document
    ↓
Policy worker summary
    ↓
Planner summary
    ↓
Coordinator summary
    ↓
Reviewer

By the time the reviewer sees the information, the original source may have disappeared.

The reviewer receives:

Coverage limit is €900.

It may not know:

• Which document said that
• Whether the document is current
• Whether it was a draft
• Whether the customer has that policy version

The claim has been transformed from evidence into “known fact”.

I think of this as evidence laundering.

A useful rule is:

Material claims should retain their evidence references as they move through the system.

Build conflict rules before production

Do not let agents invent conflict resolution during the run.

Define rules in advance.

For example:

Customer-specific contract
    >
Current approved product terms
    >
Current operational guidance
    >
Public information
    >
Training material

Or:

Structured system state
    >
generated memory summary

Or:

Current tool result
    >
worker assumption

When evidence sources disagree, the coordinator can apply the rule deterministically where possible.

If the conflict cannot be resolved safely:

human_review_required

is a perfectly valid outcome.

Test correlated failure

A particularly useful evaluation asks:

What happens when several agents receive the same wrong input?

For example:

scenario: shared_outdated_policy

policy_fixture:
  authoritative: POLICY-2026-04
  injected_retrieval_result: TRAINING-POLICY-2025

workers:
  - policy
  - claims
  - reviewer

expected:
  final_answer_released: false
  stale_source_detected: true
  escalation: true

This tests whether the architecture has any genuinely independent defence against shared bad evidence.

If every agent accepts the same source without checking it, adding more agents will not improve this failure mode.

Test one bad worker

Now invert the scenario.

Give two workers correct evidence and one worker a wrong result.

For example:

Claims worker:
approved amount = €640

Policy worker:
coverage limit = €640

Payment worker:
payment amount = €900

Expected behaviour should not be:

Majority wins.

Instead, determine why the payment worker disagrees.

Possible explanations include:

• Wrong customer
• Wrong payment
• Stale cache
• Duplicate payment
• Tool defect

The dissent may be the most important result in the run.

Voting could hide it.

Test the reviewer itself

The reviewer is another model component and needs its own evaluation.

Create cases where the draft is:

• Correct and well supported
• Correct but missing evidence
• Fluent but unsupported
• Internally consistent with stale evidence
• Contradicted by one worker
• Based on the wrong customer
• Missing one required worker
• Manipulated by instructions inside a worker response

Then measure whether the reviewer:

• Approves correctly
• Rejects correctly
• Detects conflicts
• Identifies missing evidence
• Escalates when necessary

Do not assume that adding a reviewer automatically improves safety.

Test that claim.

Test termination too

Multi-agent disagreement creates another failure mode: endless discussion.

Imagine:

Reviewer:
Evidence conflicts.

Coordinator:
Ask workers again.

Workers:
Return the same evidence.

Reviewer:
Evidence still conflicts.

Coordinator:
Ask workers again.

The system is active.

Nothing is improving.

That is a livelock.

A progress rule might be:

If two review cycles add no new verified evidence:
stop and escalate.

Also define:

• Maximum review cycles
• Maximum tasks
• Maximum retries
• Maximum messages
• Maximum duration

A trustworthy multi-agent system needs a way to admit:

We cannot resolve this automatically.

Before: three agents and a vote

Suppose we build 50 multi-agent evaluation cases.

They cover:

• Normal agreement
• One incorrect worker
• Shared bad evidence
• Missing worker
• Conflicting tools
• Stale documents
• Duplicate messages
• Review loops
• Wrong entity
• Unknown status

The original system uses majority consensus and a reviewer.

Results:

50 scenarios

Final-answer pass rate:       92%
Reviewer approval accuracy:   90%
Conflict detection:           72%
Shared-error detection:       38%
Loop termination:             80%
Unsupported releases:          6

The overall pass rate looks reasonable.

But the shared-error result is dangerous.

When several agents are wrong for the same reason, the architecture detects the problem in fewer than half of the cases.

Changes

We introduce:

• Structured worker contracts
• Evidence provenance
• Source-version validation
• Explicit conflict states
• Required-worker rules
• Deterministic arithmetic checks
• Source-priority rules
• Reviewer evaluation
• Progress detection
• Review-cycle limits
• Human escalation for unresolved conflict

Most importantly, we stop treating agent count as evidence strength.

After: independent evidence beats voting

The same 50 scenarios run again.

50 scenarios

Final-answer pass rate:       98%
Reviewer approval accuracy:   96%
Conflict detection:           98%
Shared-error detection:       94%
Loop termination:            100%
Unsupported releases:          0

The improvement did not come from adding a fourth agent.

It came from making the existing collaboration more testable.

That is an important architectural lesson.

Sometimes the answer to an unreliable multi-agent system is not:

Add another reviewer.

It is:

Improve contracts, evidence, deterministic controls, and stopping rules.

Multi-agent testing should resemble distributed-systems testing

Once several agents collaborate, test more than their individual prompts.

Test:

• Delegation
• Task contracts
• Message schemas
• Identity propagation
• Permissions
• Evidence provenance
• Shared state
• Ordering
• Duplicate messages
• Partial worker failure
• Slow workers
• Conflicts
• Race conditions
• Deadlocks
• Livelocks
• Termination
• Side effects

The final answer is only one part of the test.

You also need to know how the system reached it.

A practical test you can add today

Take one multi-agent capability and create three versions of the same scenario.

Scenario 1: independent agreement

All workers receive correct but different evidence.

Expected:

Continue.

Scenario 2: shared bad evidence

All workers receive the same outdated source.

Expected:

Detect source problem or fail the evidence gate.

Scenario 3: one dissenting worker

Two workers agree, one provides contradictory verified evidence.

Expected:

Investigate conflict, not majority vote.

Then inspect:

• Which sources each worker used
• Whether provenance survived delegation
• Whether the reviewer noticed the difference
• Whether disagreement triggered investigation
• Whether the system stopped within the defined limit

That exercise tells you far more than asking three agents the same question and counting votes.

FAQ

Does using multiple AI agents make an AI system more accurate?

Not automatically. Multiple agents can improve quality when they contribute genuinely different evidence, methods, or responsibilities. If they share the same inputs and assumptions, they can reproduce the same error.

Is majority voting a good way to evaluate AI agent results?

Sometimes, but only when the votes are sufficiently independent. Majority voting among agents using the same model and evidence can create false confidence.

Should reviewer agents use the same evidence as worker agents?

They may need the worker evidence, but important reviews should also validate evidence quality, provenance, completeness, and conflicts rather than checking only whether the conclusion follows from the supplied context.

What should happen when AI agents disagree?

Disagreement should be an explicit state. The system may gather more evidence, apply deterministic source-priority rules, use another verification method, or escalate to a human. It should not force consensus without evidence.

How do you test a multi-agent AI system?

Test individual agents and the collaboration: delegation, message contracts, evidence provenance, shared state, permissions, failures, conflicts, timing, retries, loops, termination, and side effects.

More agents are not automatically more trust

Multi-agent systems can be genuinely useful.

They can isolate capabilities.

They can run work in parallel.

They can create specialist roles.

They can add independent review.

But architecture diagrams can make a system look more trustworthy than it really is.

Three boxes labelled:

Worker
Reviewer
Verifier

do not prove that three independent checks happened.

You need evidence that the roles, inputs, methods, permissions, and failure modes are actually different enough to provide value.

This is one of the topics I explore in The AI Agent Test Manual: how to test agents as complete production systems, including multi-agent coordination, retrieval, tools, memory, evaluation pipelines, observability, and incident response.

The AI Agent Test Manual:
https://amzn.eu/d/0blIkveq

The lesson is simple:

Agreement is evidence only when you understand why the agents agree.

Three agents can be wrong together.

Test for that.