- In short
- An error propagation strategy is the end-to-end plan for how failures move through a multi-agent system. A good one avoids both anti-patterns at once: it never suppresses failures silently and never terminates the whole pipeline on a single error. Instead it returns structured error context, continues with partial results where it safely can, and annotates the gaps in the final output.
What error propagation strategy design is
Error propagation strategy design is the evaluate-level capstone of Task Statement 5.3. Where the earlier knowledge points each handle one piece, how to shape a single error, how to recognise an anti-pattern, how to classify an empty result, how to annotate a gap, this one asks you to step back and decide how failures should move through an entire multi-agent system. An error propagation strategy is the system-wide answer to a single question: when something fails at any node, what happens to the work around it and to the final output? Getting that answer right is what separates a demo that works on the happy path from a system an organisation can actually depend on.
Because it is assessed at the evaluate level, the exam will not ask you to recall a definition. It will hand you a design or a proposed approach and ask you to judge it, justify a better one, or weigh trade-offs. That demands fluency with everything upstream, which is why this knowledge point carries three hard prerequisites: the silent suppression and workflow termination anti-patterns, and coverage annotations in synthesis.
- Error propagation strategy
- The end-to-end plan governing how failures move through a multi-agent system. A sound strategy avoids both silent suppression and workflow termination, returns structured error context at each node, continues with partial results where the failure is non-critical, and surfaces the gaps as coverage annotations in the final output.
Why the choice is not suppression versus termination
The most important thing to evaluate in any proposed error propagation strategy is whether it has fallen into a false dilemma. Faced with failures, engineers often frame the decision as: should we swallow errors so the system keeps running, or should we fail hard so we never act on bad data? Both options are anti-patterns. Suppression keeps the system running by going blind to failures, which lets corrupted, incomplete output flow downstream as if it were sound. Termination protects correctness by destroying all the successful work the moment anything breaks. Choosing between them is choosing which way to be wrong.
A correct strategy refuses the dilemma. It makes every failure visible, the strength of the termination instinct, while bounding each failure's blast radius so the rest of the system keeps producing value, the strength of the suppression instinct. You get there by surfacing failures as structured context rather than swallowing them, and by isolating failures to their own branch rather than letting them unwind the whole pipeline. The exam loves a distractor that picks one anti-pattern as if it were the safe, mature choice; recognising that the real answer rejects both is the central evaluative move of this knowledge point.
The building blocks of a sound strategy
A complete error propagation strategy assembles the pieces from across the task statement into one flow. At each leaf, a failing tool or subagent returns structured error context: failure type, what was attempted, partial results, and alternatives, never an empty success. The coordinator reads that context and makes a typed decision. If the failure is a transient access failure, it retries or reroutes to a backup source; if it is a valid empty result, it accepts the answer and does not retry, applying the access-failure distinction. If the failed task is not on the critical path, the coordinator continues with the results that succeeded rather than terminating. Finally, whatever could not be completed is recorded as a coverage annotation in the synthesis, so the output is honestly scoped.
Anthropic's own engineering practice models exactly this shape. Their multi-agent research system does not restart from the beginning when errors occur; it resumes from where the failure happened, combining the model's adaptability with deterministic safeguards like retry logic and regular checkpoints, and it evaluates its output for completeness. Their broader guidance on building effective agents frames the coordinator-worker pattern in which these decisions live. And the underlying mechanism, returning is_error with an instructive message so the model can adapt, is a documented API feature, not a bespoke invention. A good strategy is mostly the disciplined composition of these established parts.
Evaluating a proposed strategy
When you are asked to assess an error propagation strategy, run it against four tests. First, are failures visible, does every error become structured context, or do any paths return empty successes that hide a problem? Second, are failures bounded, can a single non-critical failure abort work that had nothing to do with it? Third, are recovery decisions typed, does the system distinguish a retryable access failure from a valid empty result, or does it retry blindly and waste resources? Fourth, is the output honest, does the final synthesis annotate what it could not cover, or does it silently present partial work as complete? A strategy that passes all four is sound; a weakness in any one is the flaw the exam wants you to name.
This evaluative checklist is also why error propagation connects outward to the rest of Domain 5 and beyond. Deciding when a critical-path failure should stop and ask for help is the province of escalation decision analysis. Choosing the broader approach to managing limited context across a long job overlaps with context management strategy selection. And designing how failures are handled across a large parallel workload connects to batch processing strategy design. The capstone nature of this knowledge point is precisely that it forces you to reason across these boundaries rather than in isolation.
Worked example
You must evaluate two proposed error-handling designs for a multi-agent research orchestrator and recommend a sound strategy.
A team brings you two designs for a research orchestrator that fans out to several source subagents. Design A wraps every subagent in a broad try/except that, on any error, returns an empty result so the run always completes; the team praises it for never crashing. Design B aborts the entire run if any subagent fails, so the team is certain the final report never contains a half-finished section.
Evaluated against the four tests, both fail, in opposite ways. Design A fails the visibility test: its empty results are silent suppression, so the coordinator cannot tell a failed source from a barren one and the report quietly omits whatever broke. Design B fails the bounding test: one non-critical timeout destroys every successful subagent's work and forces a full, expensive re-run. Each team has optimised for one virtue at the total expense of the other.
Your recommended strategy refuses the dilemma. Each subagent returns structured error context on failure rather than an empty success, so failures are visible. The coordinator classifies each one: transient access failures get a bounded retry and then a reroute to a backup source; valid empty results are accepted without retry; a hard failure on a non-critical source is isolated and skipped while the other subagents proceed; a failure on a genuinely critical source escalates to a human. The final synthesis carries coverage annotations for anything that could not be completed. This design is both visible and bounded, makes typed recovery decisions, and produces an honestly scoped output, and articulating why it beats A and B on each of the four tests is exactly the evaluative reasoning the exam rewards.
The trade-offs you are actually weighing
At the evaluate level the exam is less interested in whether you can recite the right answer than in whether you can reason about the tensions a real design has to balance, so it helps to name them. The first tension is latency against completeness. Retrying a failed source and waiting for a backup both buy you a more complete answer at the cost of time, and there is a point past which a user is better served by a slightly thinner result delivered promptly than by a perfect one that arrives too late to matter. A sound design sets a budget for recovery rather than retrying indefinitely.
The second tension is cost against value. Every retry and every rerouted call spends tokens and money, and in a large fan-out those costs multiply. The right amount of recovery effort depends on how much the missing piece is worth: a critical regulatory finding justifies persistence and a human escalation, while a minor supporting detail does not justify three retries against a flaky source. Spending the same recovery effort on every failure regardless of its importance is a sign of a strategy that has not actually been reasoned through.
The third tension is automation against escalation. Continuing with partial results keeps the system autonomous, but some failures genuinely require a human, and knowing which is a judgement the strategy has to encode rather than dodge. A critical-path failure that no retry can fix is a moment to escalate, not to paper over with an annotation. The fourth consideration is how the strategy interacts with the execution mode: a synchronous, user-facing job favours fast degradation and prompt escalation, while a large overnight batch can afford more generous retries and checkpointing because nobody is waiting in real time. Recognising that the same failure may deserve a different response in these two settings is exactly the kind of contextual judgement an evaluate-level question is built to test.
Designing for recovery, resumption, and observability
A propagation strategy is only half a plan if it surfaces failures but has no way to recover cheaply from them, so Anthropic pairs visible errors with deterministic recovery machinery. The central technique is checkpointing: agents summarise each completed phase and persist the essential information in external memory before moving on, so a failure does not force the whole job to restart from zero. Combined with the partial-results discipline you have already seen, checkpoints are what let a long-running system resume from its last stable state rather than paying for every successful step a second time on retry.
The other half is observability. Anthropic stresses that diagnosing why agents fail requires looking at full production traces, because the same surfaced error can have very different root causes and only an end-to-end view of the run reveals which one applies. A strategy that propagates errors but records nothing about them is hard to improve, since every incident has to be re-debugged from scratch. This is also why Anthropic recommends encoding strong heuristics rather than rigid, exhaustive edge-case rules: agents operate under uncertainty, and a strategy built on flexible recovery behaviour plus good traces adapts to novel failures far better than one that tries to pre-script every error in advance.
Common misconceptions
Misconception
A mature error-handling design picks the lesser of two evils between suppressing errors and terminating the workflow.
What's actually true
Misconception
If the strategy retries failures and keeps partial results, the design is complete.
What's actually true
How it shows up on the exam
At the evaluate level, this knowledge point appears as a judgement question, usually in the Multi-Agent Research System scenario. You will be shown an error-handling approach, often one that has cleanly fallen into a single anti-pattern, and asked which design is best, or what is wrong with the proposal, or how to improve it. The decisive skill is recognising that a strong answer holds visibility and bounding together: it surfaces every failure, decides recovery from the failure type, continues with partial results off the critical path, escalates the genuinely critical ones, and annotates the gaps. An option that merely fails loudly or merely keeps running is a distractor dressed as prudence.
A reviewer proposes that, to make a multi-agent research pipeline robust, every subagent should catch all errors and return empty results so the run always finishes and never surfaces a partial section. How should an architect evaluate this proposal?
People also ask
What makes a good error propagation strategy in a multi-agent system?
How do you balance failing loudly with continuing on error?
Why is choosing between suppression and termination the wrong question?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
Anthropic's Secret: How we Build Multi-Agent AI
Why watch: Details Anthropic's production safeguards, checkpoints, resume-from-failure, and retry logic, showing a balanced error-propagation strategy that avoids both killing the whole pipeline and silently swallowing failures while keeping partial results.
More videos for this concept
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.