Error propagation across multi-agent systems
What this covers
- Return error context a coordinator can act on
- Avoid both silent suppression and total termination
- Annotate synthesis with what could not be covered
- Distinguish an access failure from a valid empty result
- Recover transient failures locally and propagate only what you could not resolve
- Choose between retry, rerouting, and a documented gap from what the report says
process plate / 5.3
Preserve successes; expose the gap
Policy and survey research succeeded. Maintenance records remain unavailable after bounded local recovery. Choose the coordinator response without erasing the successful branches.
process reading / transient + safe + budget
Retry only while all three conditions hold.
The failure is transient, another call is safe, and the bounded retry budget still has room.
Read the complete diagram as text
- Let a subagent attempt bounded local recovery for its own transient failure.
- If unresolved, propagate failure type, attempted source and query, retry count, partial findings, and suggested alternatives.
- Keep successful sibling results available to the coordinator in every branch.
- Retry safely, reroute to an acceptable alternative, or proceed with a visible gap.
- Never turn an access failure into an empty successful result.
Two common error-handling mistakes
- Silent suppression — a failed search returns empty results as success. The coordinator believes the topic was covered and found nothing. This is worse than failing, because the gap is invisible and the final answer is confidently incomplete.
- Total termination — one subagent failure ends the whole workflow, throwing away everything that succeeded.
Both replace a judgment the coordinator should make with a decision the subagent had no standing to take.
Your group project partner is assigned the archive chapter, can't get into the archive, and says nothing. The paper then reads as though that chapter held nothing worth citing. Silence and "nothing there" arrive looking identical.
What to return instead
Structured error context:
- failure type
- what was attempted — the query, the source
- partial results already gathered
- potential alternatives worth trying
That's enough for the coordinator to decide intelligently: retry, route elsewhere, or proceed with a documented gap. A generic "search unavailable" hides every one of those and leaves it guessing.
The two payloads side by side. The field names are a convention you pick, not an API contract:
silently suppressed — indistinguishable from "nothing matched":
{ "results": [] }
structured error context the coordinator can act on:
{ "failure_type": "access_denied",
"attempted": { "source": "acm-library", "query": "graph neural nets" },
"partial_results": ["arxiv:2403.01121"],
"alternatives": ["semantic-scholar", "arxiv"] }Both are a subagent reporting a failed search. Only the second lets the coordinator tell a gap from a finding, and it keeps the one paper that did come back rather than throwing it away with the error.
Access failure is not an empty result
The same distinction as 2.2, and it matters more here because the coordinator is deciding coverage.
- Access failure — could not reach the source. Needs a retry decision.
- Valid empty result — reached it, nothing matched. That's an answer.
Conflating them means either retrying a question already answered, or reporting "no findings" for a source never consulted.
Handle recoverable errors locally
Subagents handle transient failures themselves and propagate only what they could not resolve, carrying partial results and a record of the attempt.
Annotate coverage in the synthesis
The final output should say which findings are well-supported and which topic areas have gaps because sources were unavailable.
The final answer must make these gaps clear. If a third of the sources failed, a uniformly confident summary can mislead the reader even when each sentence is technically true.
structured error contextpartial resultscoverage annotations
Field note — common misconceptions
- MythThat returning empty results on failure keeps the pipeline healthy
- ActuallyThe coordinator then believes the topic was covered and found nothing, hiding the gap.
- MythThat any subagent failure should fail the workflow
- ActuallyOne failure should leave the successful work intact and reach the coordinator as a documented gap.
- MythThat a generic status is enough for the coordinator
- ActuallyThe coordinator needs failure type, what was attempted, partial results, and alternatives.
Guided review
Review this lesson as a study deck
Review the lesson's main ideas in five guided slides, then test yourself with three flashcards.
Open Task 5.3 study deckCross-domain reasoning
Connect this idea
Reliability connects the whole workflow
A reliable workflow must know when to stop, enforce required steps, return useful errors, validate results, and keep failures visible across agent handoffs.
Applied practice
Practice this lesson in a lab
Use a related lab to create a decision, implementation or diagram, evidence record, and review.
- Lab 2 · Coordinator and specialist agents
Coordinate three bounded specialists without losing provenance or hiding a coverage gap.
- Lab 10 · Reliability, provenance, and escalation evaluation
Evaluate autonomy, escalation, failure propagation, and claim-level provenance across a synthetic scenario suite.