Agentic AI Chapter 10: Error Handling and Recovery

Part of the Agentic AI study series.

Tools fail. A network call can time out, a service can return an error, or a request can be invalid. A reliable agent needs a recovery policy that protects the business operation and gives operators enough information to understand what happened.

Classify the failure first

Start by detecting and classifying the error. A transient failure, such as a timeout or temporary service error, may succeed later. A permanent failure, such as an invalid request or forbidden action, needs correction or escalation rather than repetition.

That distinction guides the recovery choice. Retry transient failures a bounded number of times, with exponential backoff and jitter to spread requests over time. A circuit breaker can stop calls to a dependency that is repeatedly failing, then allow limited checks when it may have recovered.

Choose recovery, fallback, or compensation

Use a fallback only when it is trustworthy and preserves the meaning of the task. For example, a cached read may be acceptable when it is fresh enough; a stale payment or refund status may not be. If no safe recovery is available, send the operation to a dead-letter queue with its operation ID, error category, attempt count, timestamp, and relevant order or trace references.

Recovery tries to continue an incomplete workflow. Compensation corrects or reverses effects that already happened when the workflow cannot continue. If an order return was created but label generation repeatedly fails, the system might cancel the return or route it for manual handling. That compensation is a business decision and should be explicit, not an automatic guess by the model.

Make failures observable

Logs explain individual events, metrics show patterns across many runs, and traces show how one request moved through services. Together they help answer what failed, how often it fails, and where time was spent. Keep identifiers that connect the agent run to the underlying business operation, while avoiding unnecessary sensitive data in logs.

Checkpoint: remember

• Detect and classify errors before choosing a response.
• Retry transient failures with limits, backoff, and jitter; do not retry permanent errors blindly.
• Use circuit breakers to protect repeatedly failing dependencies.
• Use fallbacks only when their results are safe and trustworthy.
• Compensate for completed side effects only through explicit business rules.
• Preserve unrecoverable operations for safe investigation and reprocessing.
• Measure recovery with logs, metrics, and traces.

← Previous: Agent Runtime Boundaries · Back to the series start