It Failed and Answered Confidently Anyway: Error Propagation in Agents

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

▶ Watch on YouTube & subscribe to The Stack Underflow

A coordinator agent fans a task out to three subagents, collects their results, and writes up a clean, confident final answer. It reads great. It’s also wrong — because subagent B failed halfway through, returned nothing usable, and the coordinator quietly stitched an answer together from the two that succeeded, presenting it as if all three had come back clean. Nobody sees an error message. Nobody sees a retry. The output just looks a little less complete than it should, in a way that’s easy to miss and expensive to trust. This is exactly the trap Domain 5 of the Claude Certified Architect exam is built to test, because it’s not really about agents at all — it’s about what a system does with a failure it doesn’t have to show you.

The one-sentence version: A coordinator that swallows a subagent’s failure and answers confidently anyway is more dangerous than one that crashes loudly, because a loud failure gets fixed and a silent one gets shipped — the fix is to propagate the error so it surfaces and, when it matters, escalates.

The question

A subagent fails, but the coordinator returns a confident final answer anyway. Problem + fix?

• A) Fine, the answer looks good
• B) The failure was swallowed — propagate/surface the error so it escalates
• C) Retry silently forever
• D) Ignore subagents

Pause here and pick an answer before you scroll — the point of these practice questions is reasoning through the mechanism, not pattern-matching the letter.

The answer

The correct answer is B. In a coordinator-subagent architecture, the coordinator fans work out and fans results back in. When one subagent errors — a tool call times out, a downstream API 500s, a parse fails — the coordinator has a choice at the fan-in point: treat the missing or malformed result as a first-class problem, or treat it as an empty slot and paper over it. Swallowing the error means the coordinator proceeds as if nothing happened, synthesizes a final answer from whatever it does have, and hands that answer to the user or caller with the same confident tone it would use for a fully successful run. The failure existed. It just never left the system.

FAN-OUT / FAN-IN — WHERE A SUBAGENT ERROR CAN GET LOST

                    ┌───────────────┐
        ┌──────────▶│  Subagent A   │──── OK ─────┐
        │           └───────────────┘             │
┌───────────────┐   ┌───────────────┐              ▼
│  COORDINATOR  │──▶│  Subagent B   │── ERROR ──▶ FAN-IN
└───────────────┘   └───────────────┘              │
        │           ┌───────────────┐              │
        └──────────▶│  Subagent C   │──── OK ─────┘
                     └───────────────┘

  At fan-in, two paths for B's ERROR:

  ✗ SWALLOWED                          ✓ PROPAGATED
  Coordinator treats B as an           Coordinator marks the
  empty/skippable result, blends       result set as PARTIAL,
  A + C into a "complete" answer.      surfaces B's error to a
  Confident tone, missing signal.      handler / escalation path.
  Nothing downstream knows B failed.   Caller sees "2 of 3 sources
                                        succeeded" or gets routed
                                        to a human / retry policy.

The fix follows directly from the mechanism: an error is data, and data that gets thrown away at the fan-in point can’t influence anything downstream — not the confidence of the final answer, not a retry decision, not an escalation to a human. Propagating the error means the coordinator’s result object carries the failure explicitly (a status field, a partial-results flag, an exception that bubbles rather than gets caught-and-ignored), so whatever consumes that result — a UI, a logging pipeline, an escalation gate — can react to it. “Propagate” doesn’t mean “crash the whole run.” It means the failure is visible to the layer that’s actually equipped to decide what happens next, instead of being decided silently, by omission, at the point where it occurred. A silent failure is the dangerous one, because nothing downstream can act on a problem it was never told about.

Why the other options fail

• A) “Fine, the answer looks good.” This confuses fluency with correctness. A confidently-written answer and a correct answer are two completely different properties, and a coordinator that lost a third of its inputs has no basis for claiming the same confidence it would have with all three. Accepting the output at face value is exactly the failure mode the question is describing, not a fix for it.
• C) “Retry silently forever.” Retrying is sometimes the right response to a transient failure — but doing it silently and unboundedly is a different problem wearing the same clothes. An unbounded retry loop has no termination condition, burns cost and latency on every attempt, and still never tells anyone a problem occurred if it eventually “succeeds” on attempt 40 with a degraded result. Retries need a bound and they need to be visible; silent and infinite is not a fix, it’s a slower version of swallowing the error.
• D) “Ignore subagents.” Throwing away the coordinator-subagent pattern because one subagent failed once is discarding the architecture instead of fixing the failure handling in it. Decomposing work across subagents exists for good reasons — smaller, focused contexts and parallelizable work chief among them. The problem in this scenario isn’t that subagents exist; it’s that a failure inside one of them never got reported. Removing subagents doesn’t remove failure modes, it just removes the structure you’d use to detect and handle them cleanly.

The concept behind it

Error propagation is a reliability discipline that shows up everywhere agents compose smaller units of work — subagents, tool calls, retrieval steps, pipeline stages. The core question is always the same: when a component fails, does the failure become visible to something that can act on it, or does it get absorbed at the boundary and disappear? Systems that fail loudly get noticed and fixed. Systems that fail silently accumulate invisible debt until the gap between “looks right” and “is right” becomes large enough to cause real damage — and by then it’s much harder to trace back to the original swallowed error.

The right target is the third row: propagate the error to a layer designed to decide what happens next, rather than letting it die at the point of failure or letting it kill the whole run indiscriminately. A few patterns build directly on this idea:

1. Design the contract, not just the happy path. A subagent or tool result should be able to represent “I failed, here’s why” as cleanly as it represents success — not force the caller to guess from an empty or malformed field. This is the same discipline covered in tool error contracts more broadly.
2. Decide what “partial” means before you ship. Does a partial result get labeled and returned, retried within a bound, or escalated? That decision belongs in the coordinator’s design, not improvised at runtime the first time a subagent fails.
3. Route on confidence once the error is visible. A propagated error is exactly the kind of signal that should feed an escalation gate — low confidence or a known failure routes to a human or a fallback path, while a clean, complete result proceeds. See When Should It Hand Off to a Human? Escalation Patterns for how that gate gets designed, and Confidently Wrong: Confidence Calibration for LLM Output for why “confident-sounding” and “actually reliable” have to be measured separately.
4. Bound your retries. If the response to a propagated error is “try again,” that retry needs a cap and a fallback, or you’ve traded a silent failure for a silent infinite loop. See Your Retry Loop Never Stops: Bounded Retries for LLM Output.

This connects back to the rest of Domain 5, too: a swallowed subagent error produces the same symptom — confident output that quietly diverges from what actually happened — as an instruction lost in the middle of a long context window, or a scratchpad that vanished on compaction. Different mechanisms, same shape of failure: something real happened to the system’s state, and nothing downstream was told. See It Forgot Your First Instruction: Lost-in-the-Middle and Context Rot and Your Scratchpad Vanished on Compaction: Persisting Agent State for two more instances of the same underlying pattern.

FAQ

Isn’t propagating every error just going to make the agent crash constantly? No — propagating an error means making it visible to a layer that can decide what to do, not automatically halting execution. A well-designed coordinator can propagate a subagent’s failure into a “partial results” status, log it, and still return a usable (clearly labeled) answer. The failure mode being fixed here isn’t “the system stopped,” it’s “the system kept going and hid that it shouldn’t have.”

How is this different from just adding a try/catch around the subagent call? A bare try/catch that swallows the exception and moves on is the swallowed-error pattern — it’s the mechanism, not the fix. The fix is what you do inside the catch: record the failure, attach it to the result object, and pass it to something that can react, rather than discarding it and returning as if the call had succeeded.

Does this apply outside of multi-agent systems — single-agent tool calls, for example? Yes. Any time one component’s output feeds another’s input — a tool call feeding a model’s next turn, a retrieval step feeding a generation step — the same choice exists at that boundary: surface the failure or absorb it. Multi-agent coordination just makes the failure easier to lose, because there are more fan-in points where an error can quietly get left out of the merge.

What’s the relationship between error propagation and confidence? They’re two halves of the same reliability loop. Propagation makes sure a failure is visible; confidence calibration and escalation thresholds decide what to do once it’s visible. A system that propagates errors but has no downstream policy for handling them just moves the silent-failure problem one layer up — the error is technically surfaced, but nothing is listening.

Where this fits in the CCA series

This is Q6 of the Domain 5 (Context Management & Reliability, 15% of the exam) practice set. Start with the Claude Certified Architect (CCA) Exam Guide for how all five domains fit together. This question sits at the intersection of reliability design and the coordinator-subagent pattern from Domain 1 — if that architecture is new to you, it’s worth reading before this mechanism fully lands. From here, the rest of the D5 set builds on the same theme of visible-versus-hidden state: It Forgot Your First Instruction: Lost-in-the-Middle and Context Rot, When Should It Hand Off to a Human? Escalation Patterns, and Confidently Wrong: Confidence Calibration for LLM Output.

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.

As of mid-2026, the CCA-F exam runs on Pearson VUE, costs $125, and allows retakes — the format is 60 questions in 120 minutes with a passing scaled score of 720/1000 across five domains. Confirm these logistics on Anthropic’s official certification pages before you register, since exam details change.

Browse all tutorials for the rest of the series.