Problem details need a retry decision
In short: Structured API errors help agents only when stable problem types map to explicit recovery actions, retry permissions and escalation boundaries.
↗IETF — RFC 9457 Problem Details for HTTP APIsRFC 9457, published in July 2023, gives HTTP APIs a common format for problem details. It is useful reading for anyone exposing tools to agents: a structured failure can carry a stable problem type alongside a human-readable explanation.
But problem details need a retry decision outside the prose. My recommendation is to map each supported problem type to an allowed recovery action. Do not ask a model to infer permission to repeat a side effect from an error message that merely sounds temporary.
What RFC 9457 actually standardises
The specification defines fields including type, title, status, detail and instance. The type identifies the problem category; detail describes this occurrence. Its security discussion also warns against exposing implementation internals through error responses.
That gives a client a consistent envelope. It does not determine whether a payment, deletion or submission is safe to repeat. HTTP's idempotency rules remain a separate part of the operation contract.
Make recovery an explicit tool policy
For a hypothetical order tool, I would maintain a small explicit mapping: invalid input returns to the caller for correction; missing authority requires an appropriate approval path; uncertain completion triggers reconciliation; a documented transient failure may permit a bounded retry.
The mapping belongs in application code and service documentation. A model can explain the result, but it should not invent a new recovery policy from the wording of detail.
The case I would test first is an unfamiliar problem type. A robust wrapper should preserve the information and stop automatic action, not treat every unknown error as a reason to try again. Likewise, a friendly message should not override an incompatible status or a known non-repeatable operation.
This is a proposed design review, not a claim that RFC 9457 prevents duplicate actions or that an agent integration was tested. The benefit is narrower: failures become easier to classify without confusing classification with authority.
What's in it for you
- Review error contracts alongside successful tool schemas.
- Make unknown problem types visible and non-automatic by default.
A standard error format tells you what failed; your application still owns what may happen next.
