When a subagent fails, it should return structured error context — failure type, what was attempted, any partial results, and alternative approaches considered — so the coordinator can decide intelligently rather than guessing from a bare failure signal.
Two fatal anti-patterns, at opposite extremes:
- Silently suppressing errors — returning an empty result as if it were success. The coordinator then reports confident findings that are actually built on missing data, with no signal anything went wrong.
- Terminating the entire workflow on one subagent's failure — a single flaky source kills a report that was otherwise 90% complete.
The correct behavior sits between these: attempt local recovery for transient failures, and propagate upward only what genuinely can't be resolved locally — including what was attempted and any partial results, not just a failure flag.
Generic statuses hide the information a coordinator needs to act. "Search unavailable" doesn't distinguish a timeout from a bad query from a rate limit from an auth failure — and each of those implies a completely different next action (retry later, fix the query, back off, refresh credentials).
Coverage annotations — structuring synthesis output to explicitly mark which findings are well-supported and which topic areas have coverage gaps due to unavailable sources — let a coordinator (or a human reader) calibrate trust in the final output appropriately.
The whole pattern in one picture: local recovery absorbs the transient case; everything else becomes structured context, never a bare status, so the coordinator — and eventually the reader — can tell what's solid from what has a gap.
The discriminator: access failure ≠ valid empty result. This is the third appearance of this exact distinction across the whole blueprint — it shows up in Domain 1's tool-execution hooks, again in Domain 2's MCP error-response design, and now here in error propagation. Three independent appearances of the same discriminator across three different domains is a strong signal it will appear on the exam form, possibly more than once.
Traps to recognize:
- Retry-with-backoff inside the subagent that, even after retries are exhausted, still returns only a generic status upward — the retry logic exists, but the propagation problem is untouched.
- Catching a timeout and returning an empty result marked as successful — this is the silently-suppressed-error anti-pattern by another name.
- Propagating the raw exception to a top-level handler that simply ends the entire run — the opposite failure mode, discarding 90% good work over one bad source.