Learn · Context management & reliability · CCAR-F task 5.3

Error propagation across agents

When a subagent fails, the coordinator must know what failed, why, and whether to retry. Never let "failed" look like "empty".

Key ideas

• Distinguish "empty" (searched, found nothing) from "failed" (could not search). An error must never look like an empty result.
• Subagents return structured errors to the coordinator: what failed, a category, whether it is retryable, and a readable detail.
• Return partial results with a clear marker of what is missing, instead of failing the whole task.
• The coordinator decides retry vs alternate source vs escalate or report, based on the error category.
• The final output names its gaps, so readers know what was not verified.

Worked example: A structured subagent error

The field names are a convention you define for your own system, not API fields. What matters is that the coordinator can tell what failed, whether to retry, and what it still has.

Exam traps

• A subagent that catches an exception and returns "no results", so the coordinator reports a false negative.
• Letting one subagent's failure abort the whole run and throw away the good results.
• Retrying every error blindly: a permission or bad-input error won't fix itself on retry.
• Passing back only a generic "operation failed", which gives the coordinator nothing to choose a recovery from.

Official docs

• Create custom subagents
• Tool use with Claude

Practise CCAR-F questions · Next lesson: Context in large codebases