Error propagation across agents

• Structured error context: failure type, attempted query, partial results, alternative approaches.
• An access failure (timeout, service down) needs a retry decision; a valid empty result is a successful query with no matches.
• Generic statuses such as "unavailable" hide everything the coordinator needs.
• Two anti-patterns: suppressing errors by returning empty results as success, and terminating the whole workflow on a single failure.
• Subagents recover locally from transient failures and propagate only what they cannot resolve, with attempts and partials attached.
• Synthesis output carries coverage annotations: which findings are well supported and which topics have gaps because sources were unavailable.

• Design the error payload a subagent returns to its coordinator.
• Separate access failures from valid empty results in reports.
• Place retry logic at the right level (inside the subagent for transient errors).
• Make gaps visible in the final report instead of hiding or omitting them.

• "An empty list is the safe way to report a failure." It is the most dangerous: the gap disappears.
• "One failure should abort the run so nothing wrong ships." A partial result with a noted gap is usually the better outcome.
• "The coordinator will retry anyway, so a generic status is fine." It cannot retry well without knowing what failed.

Options that route every blip to the coordinator (latency), hand every failure to a human (cost), or finish the run with a clean-looking but incomplete report (safety). The best answer keeps the information flowing and the decision with the coordinator.

• 2.2Structured error responses
• 1.2Coordinator-subagent orchestration
• 5.6Provenance and uncertainty