When Two Agents Disagree, Who Decides? The Coordinator-Subagent Pattern

July 24, 2026 · Claude Certified Architect (CCA) Prep (part 8)

▶ Watch on YouTube & subscribe to The Stack Underflow

You fan a task out to two sub-agents because that is supposed to be the fast, thorough way to get an answer — one agent checks the database, another checks the docs, and the orchestrator stitches the result together. Then they come back with different answers. Not a crash, not an error — two confident, well-formed, contradictory answers. Now what does the orchestrator do with them? Most people who have never designed a multi-agent system reach for the obvious move: pick one and move on. That instinct is exactly what this question is built to catch.

The one-sentence version: When sub-agents disagree, the orchestrator does not pick a winner arbitrarily — it routes both answers into a reconcile (critic) step that decides, so disagreement becomes a signal instead of a coin flip.

The question

Two sub-agents return conflicting answers to the orchestrator. Best design?

• A) Return the last one
• B) Return the first
• C) A reconcile/critic step decides before responding
• D) Ask the user every time

Pause here and pick an answer before you keep scrolling.

The answer

The answer is C — a reconcile/critic step decides before responding.

The mechanism is a fan-out/fan-in shape, not a straight line. The orchestrator dispatches the same task (or two angles on it) to Agent A and Agent B in parallel. Both results land — but instead of flowing straight back to the user, they both feed into a dedicated reconcile node: a critic step whose only job is to compare the two answers, decide which one is correct (or synthesize a third answer from both), and then hand a single answer back to the orchestrator.

                ┌──────────────┐
        ┌──────▶│   AGENT A    │──────┐
        │       └──────────────┘      │
 TASK ──▶                             ▼
        │       ┌──────────────┐    ┌────────────────────┐    ┌────────┐
        └──────▶│   AGENT B    │───▶│  RECONCILE (critic) │───▶│ ANSWER │
                └──────────────┘    └────────────────────┘    └────────┘

  ✗ last-writer-wins:  A ──▶ B ──▶ (B silently overwrites A) ──▶ ANSWER
                        this path throws away A's work with no comparison

Why this beats the obvious shortcuts comes down to one idea: fan out to explore, reconcile to decide. Sending the same problem to two agents is only useful if you actually use both results. If the orchestrator just keeps whichever one finished last (or first), the fan-out step was theater — you paid for two agent runs and used the information from exactly one of them. The reconcile step is what turns “we ran two agents” into “we got a better answer than either agent alone would have produced.” It can be as simple as a rules-based comparator (do the two numbers match within tolerance? flag if not) or as sophisticated as a third LLM call acting purely as a judge, given both answers and the original task, and asked to decide or merge.

This is the same shape you’ll see under different names across the industry — “critic model,” “verifier agent,” “judge pass,” “voting/reconciliation layer.” The label varies; the mechanism is constant: never let two independent outputs merge silently. Merging requires a decision, and a decision requires a step that is responsible for making it.

Why the other options fail

• A) Return the last one. This is last-writer-wins, and it is arbitrary. “Last” usually just means “whichever agent happened to finish its network calls slower” — a timing accident, not a quality signal. If Agent A was right and Agent B was wrong but slow, the orchestrator now confidently returns the wrong answer.
• B) Return the first. Same failure, opposite direction. “First” rewards whichever agent did the least work or hit the shortest tool-call path — which correlates with speed, not correctness. A sub-agent that skipped a verification step will often answer fastest and most confidently wrong.
• D) Ask the user every time. This looks safe — when in doubt, defer to a human — but it does not scale and it is not architecture, it is an escape hatch. If every disagreement between two sub-agents becomes a support ticket back to the user, you have built a system that cannot resolve its own internal state, which defeats the point of automating the task at all. Escalation to a human has a place (see the concept section below), but it is the fallback after reconciliation fails or confidence stays low — not the default response to any disagreement.

The common thread in A, B, and D is that none of them actually evaluate the two answers. They either pick based on an accident of timing or push the decision entirely outside the system. Only C introduces a step whose explicit job is to look at both answers and reason about which is right.

The concept behind it

This question is really testing whether you understand result aggregation in multi-agent orchestration — one of the core architectural decisions in any system where an orchestrator dispatches work to more than one sub-agent. It shows up in three shapes, and the CCA exam (and real systems) will test all three:

The reconcile pattern only matters in the middle row — where the sub-agents’ outputs can genuinely conflict because they’re answering the same question from different angles. If Agent A and Agent B are working on disjoint pieces of a task, there’s nothing to reconcile; you just concatenate. The exam-style trap is presenting a fan-out/fan-in scenario and hoping you reach for “just pick one” instead of recognizing that overlapping answers need a decision step.

A few design details that separate a working reconcile step from a decorative one:

• The critic needs the same evidence both agents had, not just their conclusions. A judge that only sees “Agent A said 42, Agent B said 47” without any of the underlying reasoning is guessing too — just with extra steps. Pass through the intermediate reasoning or tool outputs, not just the final answer.
• Disagreement rate is itself a useful signal. If two independently-run agents disagree constantly on the same class of task, that’s not a reconciliation problem — it’s a sign the sub-agent prompts, tools, or scoping are inconsistent upstream. Track it.
• Reconciliation has a ceiling. If the critic step itself can’t confidently decide — both answers look equally plausible, or the confidence gap is small — that’s exactly the point where escalation to a human (option D, but used correctly) becomes the right move. The reconcile step’s job includes knowing when it is unsure.
• This is architecturally distinct from a single subagent retrying itself. A subagent that reflects on its own output and revises is self-correction inside one agent’s loop. A reconcile step across two independently-run agents is a coordination decision at the orchestrator level. Both matter, but they solve different failure modes — one catches an agent’s own mistake, the other catches disagreement between two agents that each thought they were right.

FAQ

Isn’t asking the user simpler and safer than building a reconcile step? It feels safer in the moment, but it doesn’t scale and it isn’t a substitute for reconciliation — it’s what you fall back to after reconciliation can’t resolve the disagreement with confidence. A system that escalates every sub-agent disagreement to a human has effectively outsourced its orchestration logic to the user, one ticket at a time.

What does the reconcile/critic step actually look like in code? It can be as light as a comparator function checking whether two structured outputs agree within a tolerance, or as heavy as a third LLM call given both candidate answers, the original task, and the intermediate evidence, and prompted specifically to judge or merge them. The complexity should match how often and how badly the sub-agents are expected to disagree.

Does this only apply to two sub-agents, or does it generalize to more? It generalizes — this is the same idea behind majority-vote and self-consistency ensembling with three or more parallel runs. The reconcile step just becomes a voting or ranking function instead of a pairwise comparison. The architecture is identical: fan out, converge, decide.

How is this different from a supervisor agent just re-running the task itself? Re-running the task is a retry, not a reconciliation — it throws away both prior answers and starts over, which is expensive and doesn’t use the information you already paid for. A reconcile step is cheaper: it reasons over the two answers you already have instead of generating a third from scratch.

Not affiliated with, authorized, or endorsed by Anthropic. “Claude” and “Claude Certified Architect” are trademarks of Anthropic. These are original practice questions for study, not real exam content — verify current exam details on Anthropic’s official pages.

Where this fits in the CCA series

This question sits in Domain 1 — Agentic Architecture & Orchestration, the heaviest single domain on the exam blueprint (as of mid-2026, roughly 27% of the exam — verify the current weighting on Anthropic’s official pages). Reconciliation is what happens after the agent loop produces an observation you actually feed back into context — if that step is broken, see The Agent Loop Explained: Why Ignoring Tool Results Breaks Your Agent. It also assumes the sub-agents themselves know when to stop iterating rather than looping forever, covered in Why Your Agent Loops Forever: Termination Conditions in the Agent Loop. And when reconciliation genuinely can’t resolve a disagreement, the next question is where the human enters the loop — start with Where Does an Agent Remember Last Week? Session State vs Long-Term Memory for the memory side of multi-agent state, and if you haven’t yet, work through the whole domain map in the Claude Certified Architect (CCA) Exam Guide.

For more practice questions and the full five-domain series, browse all tutorials.