Error propagation across multi-agent systems
Implement error propagation strategies across multi-agent systems.
This subtopic (5.3) sits in Context Management & Reliability (D5) on Anthropic's Claude Certified Architect — Foundations (CCA-F) exam. The bank holds 15 practice questions here — 3 easy, 8 medium, and 4 hard — with 5 free to try, answers and explanations included. 3 of the free questions are below; the rest are in the practice stream.
What the exam tests here
- structured error context — failure type, attempted query, partial results
- silent error suppression anti-pattern — returning empty as success
- distinguishing access failures from valid empty results
- total workflow termination on single failure anti-pattern
Free practice questions: Error propagation across multi-agent systems
Your support agent calls lookup_order with a partial order ID. The MCP tool times out against the backend, catches the exception, and returns { "orders": [] } with no is_error flag. The agent reads zero results and tells the customer no order exists, then offers to escalate_to_human only on explicit request. What is the primary fix to this error-propagation flaw?
Show answer & explanation
Correct answer: D. Make lookup_order return a tool_result with is_error: true and a structured error message so the agent distinguishes 'no orders found' from 'lookup failed'.
The Messages API's tool_result block supports is_error: true, which lets a tool faithfully signal 'lookup failed' versus 'no records exist'. Restoring that signal lets the agent reason correctly about the empty payload. 'Wrap lookup_order in a PreToolUse hook that retries' is correct only for transient errors and still loses the failure signal if all retries fail. 'Add an instruction in the agent's system prompt requiring it to escalate' relies on probabilistic compliance and conflates legitimate 'no orders' cases with failures. 'Change lookup_order to return isRetryable: true' invents a sidecar field instead of using the standard error channel.
A slash command in .claude/commands/ queries a file index tool and receives an empty array. The command treats this identically to a permission-denied error and aborts. What is the architectural problem?
Show answer & explanation
Correct answer: B. The command conflates a valid empty result with an access failure, causing unnecessary aborts on legitimate zero-match queries.
An empty array is a valid successful response meaning zero matches; treating it as a failure is a classification error. 'Slash commands cannot invoke external tools' is false — commands can call any available tool. 'Return null instead of empty array' inverts correct API design; empty arrays are the idiomatic success response. 'Retry up to three times' addresses transient failures, not the misclassification of valid results.
The coordinator agent delegates a literature search to the web search subagent via the Task tool. The subagent's search query times out. The subagent returns an empty results array with a success status. The coordinator agent proceeds to synthesize a report from zero sources. What error handling principle was violated?
Show answer & explanation
Correct answer: B. Returning an empty array with success status suppresses the timeout error, preventing the coordinator from distinguishing a genuine zero-result search from a failure
Returning an empty array with a success status is the silent error suppression antipattern — the coordinator agent receives a result indistinguishable from a valid zero-result search, so it proceeds with synthesis on missing data. 'Retry with a shorter timeout...' addresses retry strategy but does not fix the suppression. 'Coordinator validates non-empty arrays...' partially mitigates the problem downstream but does not fix the subagent's incorrect signaling. 'Task tool auto-retries...' is not how the Task tool works and moves responsibility away from the subagent.
2 more free questions on this subtopic in the practice stream, plus 10 in the full bank. Keep practicing →