Skip to content

Article / Error semantics

Typed tool errors as control signals for AI agents

A stable error code tells an agent which recovery branch is available. Free-form failure prose may help a person, but it is too ambiguous to serve as the only control signal in a stateful tool loop.

For
Tool authors and agent developers designing reliable error recovery
Outcome
Map expected failures to bounded agent actions without hiding terminal errors

Short answer

Typed errors turn failure into explicit control flow

The tool should return a stable machine-readable code, safe structured details, and a clear statement that no mutation occurred when that is the contract.

An agent can map a version conflict to reread, a schema error to payload repair, a rate limit to bounded backoff, and an authorization failure to stop. If all four arrive as an undifferentiated message, the model must infer control flow from prose and may choose an unsafe branch.

The code does not need to expose internal stack traces or database details. It should communicate the minimum semantic fact required for safe recovery.

Control matrix

Every expected error should have a bounded recovery policy

Example error-to-action mapping
Error meaningSafe next stepUnsafe shortcut
Invalid inputRepair against the published schemaKeep resending the same payload
Version conflictReread state and decide againChange only the version number
Rate limitedWait according to the returned policyBurst parallel retries
UnauthorizedStop and surface the boundaryProbe identifiers for access
Terminal aggregateStop mutation attemptsRetry until a call slips through

Evaluation

Preserve the original error and the recovery sequence

A final success should not erase the initial failure because the repair path is part of the agent's observable behavior.

Record the attempted tool and payload, stable error code, any retry guidance, subsequent reads, repaired request, and final authoritative effect. That sequence distinguishes first-pass correctness from successful recovery.

It also exposes retry loops. Ten identical failures followed by abandonment should not be summarized as one harmless error simply because the interface collapsed duplicate messages.

Boundary

Typed errors improve recoverability but do not choose for the agent

The contract can identify the failure class and available next step; the agent still has to use current context, respect budgets, and know when to stop.

  • Keep error codes stable across equivalent failures.
  • Validate any structured error details at the client boundary.
  • Do not mark an unexpected internal defect as a routine retryable condition.
  • Evaluate whether the agent selected the correct recovery branch, not merely whether an error object existed.

Next step

Inspect structured MCP responses

Review the current tool contracts before defining recovery branches.

Inspect structured MCP responses