Implement error propagation strategies across multi-agent systems

In a coordinator-subagent system, subagents fail all the time: a search API times out, an MCP tool returns a 503, a document is unreachable. The reliability of the whole system depends less on preventing these failures than on how failure information travels back to the coordinator. The coordinator is the only component with a global view, so it is the right place to decide whether to retry, try an alternative source, or proceed with reduced coverage. A subagent that hides or flattens its failure robs the coordinator of the context it needs to recover.

The governing principle: propagate enough structure that the coordinator can make an intelligent decision, but no more than it needs. This mirrors the MCP structured-error pattern (isError, errorCategory, isRetryable) from tool design, applied to the agent-to-agent boundary. Errors are data that flow through the system, not exceptions that halt it.

When a subagent cannot complete its task, it should return a structured error object, not a bare string. The four fields the exam expects are: (1) failure type (timeout, permission, rate limit, not found), (2) what was attempted (the exact query or operation), (3) partial results already gathered, and (4) potential alternative approaches.

Example:

{
  "status": "error",
  "failureType": "timeout",
  "attemptedQuery": "AI impact on film production 2024",
  "partialResults": [{"url": "...", "excerpt": "..."}],
  "alternatives": ["retry with narrower query", "use news API instead of web crawl"]
}

With this, the coordinator can retry with a modified query, delegate to a different source, or accept the partial results and annotate the gap. A bare "search failed" forces the coordinator to either blindly retry or give up, neither of which is an informed decision.

This distinction is subtle and heavily tested. An access failure means the query never really ran: a timeout, a 503, an auth error. It needs a retry-or-alternative decision. A valid empty result means the query ran successfully and simply found nothing, zero matching orders, no articles on the topic. That is a successful outcome, not an error.

Conflating the two is expensive in both directions. If you report an empty result as an error, the coordinator wastes retries on a query that will always return nothing. If you report an access failure as an empty result, the coordinator believes a topic has no sources when the truth is that the source was unreachable, and the final report becomes silently incomplete. Always encode which of the two actually occurred so the coordinator responds correctly.

Not every failure should reach the coordinator. Transient failures (a single timeout, a momentary rate limit) are best handled locally by the subagent: retry with backoff, try a fallback endpoint. Only when local recovery is exhausted should the subagent propagate, and when it does, it must include what was attempted and any partial results, not just a terminal status.

This keeps the coordinator focused on decisions it alone can make (re-scoping, cross-agent trade-offs) rather than drowning in low-level retries. It also preserves progress: a subagent that gathered three of five sources before failing should hand those three upward, not discard them. Local recovery for the routine case, structured propagation for the unresolvable case.

Error propagation does not end at the coordinator; it must survive into the final output. When some subagents returned partial or empty results, the synthesis agent should annotate coverage: which findings are well-supported by multiple sources, and which topic areas have gaps because a source was unavailable.

This is the difference between a report that says "AI has no measurable impact on film" (false, the film search timed out) and one that says "film production could not be assessed because the primary source was unreachable." Coverage annotations turn a silent hole into an explicit, actionable caveat that both the reader and the coordinator can act on.

Two opposite mistakes both break reliability. At one extreme is silent suppression: catching an error and returning empty-but-successful, so failure looks like success and the workflow produces confidently incomplete output. At the other extreme is fail-fast termination: letting a single subagent's exception abort the entire multi-agent run, so a recoverable timeout destroys hours of parallel work from other agents.

The correct posture sits between them: surface the failure with structure, let the coordinator decide, and degrade gracefully. A single failed subagent should reduce coverage, not kill the run, and reduced coverage should be visible, not hidden. The exam frequently presents these two extremes as the wrong answers flanking the structured-context correct answer.