CCAR-F - Context Management & Reliability (15% of the exam) - Section 5.3

Implement error propagation strategies across multi-agent systems.

Structured error context carrying the failure type, the attempted query, partial results and possible alternatives is what lets a coordinator recover intelligently. A generic status such as search unavailable hides everything useful. Two anti-patterns sit either side of the correct behaviour: silently suppressing an error by returning empty results as success, and terminating an entire workflow on a single subagent failure. Coverage annotations mark which findings are well supported.

structured error contextgeneric error status as an anti-patternsilent suppression of failureslocal recovery before propagationcoverage annotations in synthesis

Practice question for this objective

Free sampleContext Management & Reliabilitymedium

The Atlas Research team runs a multi-agent research system on the Claude Agent SDK, where a coordinator decomposes a question and delegates to web search, document analysis, synthesis and report generation subagents. When a web search subagent cannot reach a source, it returns the single line "status: error" to the coordinator. Telemetry across 1,200 runs shows the coordinator reissuing the identical query an average of 3.4 times before abandoning the branch, and 94 percent of those repeat attempts fail in exactly the same way. Which change most effectively addresses the retry behaviour?

ARaise the coordinator's per-branch retry ceiling from three attempts to eight, so that a source suffering a transient outage has longer to recover before the branch is abandoned.
BRoute the failing source lookups through the Message Batches API so that the repeated attempts run asynchronously and no longer hold up the coordinator's other research branches.
CAdd few-shot examples to the coordinator's system prompt showing how to react to a failed search, so that it gives up on a fruitless query after fewer attempts than it does today.
DHave the subagent return a structured error payload naming the failure type, the source that failed and any partial results it had already gathered, so the coordinator can select a different branch. Correct

A generic error status gives the caller nothing to reason about, so errors crossing an agent boundary must carry structured, actionable context. The retry loop is driven by information starvation, not by faulty judgement. A bare status string collapses throttling, an unreachable host and an empty result set into one indistinguishable outcome, so the only move left to the coordinator is to try again. Returning the failure class, the source identity and any partial findings restores the distinction and lets the coordinator branch correctly on the first failure.

Why A is wrong: It is tempting because retrying does clear genuinely transient faults, and the current ceiling looks like the tuning knob nearest the symptom. It is wrong because the coordinator still cannot tell a transient fault from a permanent one, so a higher ceiling multiplies the 94 percent of attempts that were already futile.

Why B is wrong: It is tempting because asynchronous processing genuinely removes blocking cost and the batching window is real. It is wrong because it changes when the futile retries run rather than whether they run, so the same 94 percent failure rate persists at a longer latency.

Why C is wrong: It is tempting because few-shot prompting does shape agent behaviour and costs little to try. It is wrong because the coordinator is not misjudging a rich signal, it is receiving none, and no example can teach it to read information the error payload does not contain.

Why D is correct: Correct. The coordinator retries blindly because a bare status string carries no information it can act on. A structured payload distinguishing a retryable throttle from a dead source, plus whatever was gathered, lets the coordinator retry, substitute a source or move on deliberately.

See more CCAR-F practice questions, answers explained.

Exam traps in Context Management & Reliability

Answers that look right on this material and are not. Each one is a distractor from a different question in the CCAR-F bank for this domain.

The coordinator can infer the failure class from which subagent produced the payload, because each specialist fails in a characteristic way, so a fixed redispatch policy of two attempts remains adequate.
Why it is wrong: Tempting because specialists do have typical failure modes, but the stem shows one subagent producing both transient and permanent failures, so the sender identifies the stage rather than the cause.
The coordinator's context window had filled with findings returned earlier in the run, so the four extraction failures were evicted from its history before synthesis was dispatched.
Why it is wrong: Tempting because context pressure genuinely degrades long coordinator runs, but eviction cannot remove observations that were never present: the failures occurred inside a separate context that the coordinator never held.
Dispatch the four subagents one after another rather than in parallel, so that the coordinator can compact its conversation between each return and keep the transcript within a workable size.
Why it is wrong: Tempting because it does bound the peak context, but it multiplies wall clock time by four, leaves the rediscovery untouched and relies on compaction to discard detail the synthesis may still need.

More in this domain

Back to all Context Management & Reliability objectives, or the CCAR-F cert hub.

Examworthy is not affiliated with or endorsed by Anthropic. Original, blueprint-aligned practice material only.