Lesson 5: Failure and Coordination

Learning goals:

• Explain why a subagent claiming it's "done" can't be taken at face value, and why you need an independent way to verify
• Recognize the two common failures in multi-agent collaboration: duplicate work and conflicting results
• At the result-integration stage, know how to deduplicate and how to handle contradictory outputs

Prerequisites: complete Lesson 4, able to tell the three collaboration patterns apart and handoff | Prev: Lesson 4 << | Next: Lesson 6 >>

Two subagents each research the same cloud provider's starter plan. One reports back that it starts at $20 a month, the other says $25 — and both outputs confidently mark themselves "verified, no errors." The earlier lessons all covered how to stand up multi-agent collaboration; this one covers where it breaks down after you've built it — a subagent's self-reported status can't be trusted, duplicate work, conflicting results — and what the orchestrator should do about each.

A subagent saying "done" doesn't mean it got it right

When a subagent returns a result, it usually tacks on a line like "complete" or "verified, no errors." That statement isn't evidence — it's just the subagent's own summary of its own output, and that summary can be wrong. The official observation of agent behavior is exactly this: "Claude stops when the work looks done. Without a check it can run, "looks done" is the only signal available, and you become the verification loop: every mistake waits for you to notice it."¹ Which is why the official advice is to "Have Claude show evidence rather than asserting success."¹

The official docs call this the trust-then-verify gap: "The trust-then-verify gap. Claude produces a plausible-looking implementation that doesn't handle edge cases. Fix: Always provide verification (tests, scripts, screenshots). If you can't verify it, don't ship it."¹ That advice was written about writing code, but the same logic applies to any delegation: what a subagent hands back reads smoothly, has the right format, looks like it was done carefully — and all of that is just "plausible-looking," which isn't the same as actually correct. If the orchestrator takes a subagent at its word that it's "done" and splices the output straight into the final result, it has skipped verification entirely.

How to verify: set a checkable standard for a subagent's output

"Don't take it at face value" is easy to say; the hard part is how to verify. Reading it once and deciding it "looks fine" isn't verification — that's still stuck in the first half of the trust-then-verify gap. The reliable approach is to define a concrete, checkable standard first, then measure the subagent's output against it.

One standard used in a production system looks like this: "We used an LLM judge that evaluated each output against criteria in a rubric: factual accuracy (do claims match sources?), citation accuracy (do the cited sources match the claims?), completeness (are all requested aspects covered?), source quality (did it use primary sources over lower-quality secondary sources?), and tool efficiency (did it use the right tools a reasonable number of times?)."² What these five criteria share is that each one can be checked concretely, not scored on impression. Factual accuracy can be checked line by line against the sources the subagent cited; completeness can be checked against every requirement listed in the task description, to see whether they were all covered; tool efficiency can be read straight off the call log, to judge whether there were obviously redundant or duplicate calls.

Bringing this into your own collaboration setup, the first step in verifying a subagent's output isn't to ask "does this look right," but to ask "for this task, which criteria can I check concretely" — list them out, then measure the output against each one.

Duplicate work: several subagents doing the same thing

Lesson 3 covered how a task description that isn't detailed enough leads to subagents that "misinterpreted the task or performed the exact same searches as other agents."² That's the root cause, but the failure usually only surfaces at the moment results are aggregated — the orchestrator receives several subagent outputs and finds that two of them overlap heavily, covering the same thing in different words.

Duplicate work isn't a catastrophic error in itself — the content isn't wrong, it just wastes the tokens and calls that should have covered a different angle. But it's a signal: some subagents' task boundaries weren't drawn clearly enough, and it's worth going back to check the task descriptions from the dispatch step, rather than just manually deduplicating this one batch of results and calling it done. When you spot duplicate work, rather than only deleting the repeated content, it's more worthwhile to figure out why it repeated — whether the two task descriptions overlapped in scope, or the subagents each drifted toward the same, most obvious direction.

Conflicting results: two subagents reach contradictory conclusions

Trickier than duplicate work is a result conflict — like the scene that opened this lesson: two subagents each do their own research and hand back conclusions that contradict each other, one saying the starter plan starts at $20 a month, the other saying $25. You can't deal with this by "just picking one" or "splitting the difference" — both approaches risk serving up a wrong number as the final conclusion.

When you hit a result conflict, the sensible order is: first look at what each side based its answer on — did they consult different sources, one using the provider's current live page and the other accidentally using a cached old page; if the basis can be traced, you can usually tell which one is more trustworthy and replace the unreliable one; if the basis itself can't settle who's right, don't make the call yourself during integration — flag the contradiction as-is for human review, or spin up a new subagent specifically to verify that one point of disagreement. The problem a result conflict exposes is usually more worth worrying about than duplicate work — it means at least one subagent output is wrong, and if you drop it into the final result unhandled, you've packaged an unverified error as a "done" conclusion.

Result integration and dedup: what the orchestrator does to wrap up

Stitching several subagent outputs into a final result isn't a matter of concatenating them end to end — it means running back through the categories of problem above: is there duplicate content that needs merging, are there contradictory conclusions that need verifying or flagging, does every claim trace back to a corresponding basis. That last point is especially easy to overlook — Lesson 3, "Writing Prompts for Delegation," mentioned that the production system set up a dedicated agent, described as "a CitationAgent, which processes the documents and research report to identify specific locations for citations. This ensures all claims are properly attributed to their sources."² The same logic holds at the integration stage: once several subagent outputs are pooled together, it's easy to get misattribution — writing up data that subagent A found as a conclusion about the company subagent B was responsible for. Verifying the source attribution of each claim at the integration stage matters just as much as verifying whether the facts themselves are accurate.

Dedup, verifying conflicts, and checking source attribution — those three together are the real work of the "aggregate" step, and not, as Lesson 2 warned, just concatenating the subagents' raw replies and calling it done.

Recap

• "Done" or "verified, no errors" when a subagent returns is just a self-report, not evidence. Without a check it can run, "looks done" is the only signal available¹; the official docs are explicit that Claude "produces a plausible-looking implementation that doesn't handle edge cases," and if you can't verify it, don't ship it.¹
• Verification can't stop at "reads fine" — define checkable criteria for the specific task, like the rubric the official LLM judge worked from, where factual accuracy, citation accuracy, completeness, source quality, and tool efficiency can each be checked line by line.²
• Duplicate work is a common consequence of task boundaries that weren't drawn clearly², usually surfacing only when results are aggregated; spotting a duplicate isn't just deleting the extra content, it's worth going back to check the task descriptions from the dispatch step.
• Conflicting results — two subagents reaching contradictory conclusions — can't be handled by picking one at random or splitting the difference; verify the credibility of each side's basis first, and when you can't rank them, flag the conflict as-is for human review.
• The integration stage does three things at once: dedup, verify conflicts, and check whether each claim's source attribution is misattributed² — that's the real work of the "aggregate" step, not just concatenating the subagents' raw replies.

>> Lesson 6: Hands-On: Building a Two-Agent Review Pipeline