Errors that travel well between agents

In the research system, a search subagent queries six sources and one responds with a 403. What it returns to the coordinator decides whether the final report is useful, misleading or never produced at all.

What the coordinator needs

The coordinator decides how to recover: retry later, try another source, continue without that part or escalate. For that it needs structured error context:

• failure type: transient (timeout, 503, rate limit) or permanent (401, 403, 404, malformed query);
• whether it can be retried;
• what was attempted: the source and the exact query;
• partial results: what was obtained from the other five sources;
• possible alternatives: another source, another query.

A generic status such as “search unavailable” or “Error: search failed” hides all of that. The coordinator does not know whether to wait, change course or give up.

Empty is not the same as failed

Case	What happened	What the coordinator does
Valid empty result	The search ran and found nothing	Treats it as data: there is no evidence there
Access failure	The search could not run (timeout, permissions)	Decides whether to retry or find another source

If the subagent reports both the same way, the coordinator will conclude “there is nothing” when in fact nobody could look.

The two anti-patterns

• Silent suppression: the database fails and the subagent returns zero results as success. A variant: it processed 320 of 500 invoices and reports “all processed”. The coordinator has no reason to look for alternatives and the report states something false. The right move is to return the error with how many were processed and how many there were.
• Terminating everything on one failure: one of five parallel subagents fails and the coordinator aborts the workflow. The other four branches had value. They are kept, the failed branch is marked as missing and the output states the gap.

Local recovery first

Not every error has to go up. The subagent retries transient errors locally, with backoff: a 503 or a rate limit usually clears on its own. It only propagates what it cannot resolve, together with what it attempted and the partial results.

Permanent errors are not retried: repeating the same thing does not fix an invalid key. If the pricing subagent gets a 401, the pricing dimension is marked as unavailable, no figures are estimated and the configuration fault is escalated to a person.

The synthesis states what is missing

The final report cannot sound equally confident everywhere if part of the evidence never arrived. It is built with coverage annotations: which findings are well supported and which topic areas have gaps because a source was unavailable, naming the source and the kind of evidence it was expected to provide.

The typical traps

• A generic error message, with no type or query.
• Returning empty as success when there was a failure.
• Aborting the whole workflow because one subagent went down.
• Retrying permanent errors, or sending every transient error up to the coordinator.
• A report that does not mention the missing source.

On the exam

If the question is what the subagent returns, look for the option with failure type, what was attempted and partial results. If it is how the system continues, the one that keeps what worked and states the gap. If the error is transient, the one that retries locally before propagating.