Question 1 · choose 1
Your document-analysis subagent calls a PDF service that returns a transient 503 about once in twenty calls; an immediate retry almost always works. Today every 503 goes straight back to the coordinator, which re-plans the whole research step and slows every run. How should errors be handled?
- ALet the subagent retry transient failures itself, within a limit, and report what still fails
- BHave the subagent skip a document whenever the service fails and carry on without mentioning it
- CStop the whole research workflow on any error, so that no report is built from incomplete analysis
- DKeep sending every error to the coordinator, which sees the whole plan
Show the answer and why
ALet the subagent retry transient failures itself, within a limit, and report what still fails
Correct
Local recovery handles routine transient errors where they happen, and the coordinator hears only about problems it must decide on.
BHave the subagent skip a document whenever the service fails and carry on without mentioning it
Incorrect
Silently dropping documents hides gaps that the final report should disclose.
CStop the whole research workflow on any error, so that no report is built from incomplete analysis
Incorrect
Terminating everything on one transient failure throws away the work that succeeded.
DKeep sending every error to the coordinator, which sees the whole plan
Incorrect
This is the current design; routine retries do not need re-planning and only slow the run.
Subagents should recover locally from transient failures and propagate only the errors they cannot resolve, with what was attempted and any partial results. Both silent suppression and aborting the workflow are anti-patterns.
Anthropic documentation