AI agent error handling: retry, resume, or escalate?

When an AI agent completes only part of a task, it should preserve the confirmed results, distinguish failed steps from steps with an unknown outcome, and choose a recovery action that will not repeat unintended changes. Retrying the entire request is often the wrong response to an uncertain write. First determine what happened in the target system; then retry, resume, correct, or ask for help according to the operation's behavior.

In enterprise automation, autonomous AI agents are increasingly entrusted with complex, multi-step orchestration workflows: synthesizing customer requirements, creating new JIRA tickets, reserving inventory in SAP, provisioning AWS infrastructure, and sending customer confirmations via email. In a multi-step execution plan comprising five discrete tool calls, failure at step four is not a simple boolean failure. If the agent crashes, times out, or encounters an authorization error midway through execution, naively aborting the workflow leaves dangling records, half-provisioned cloud resources, and locked database rows. Conversely, naively restarting the entire workflow from step one risks creating duplicate payment charges, re-issuing duplicate tickets, and spamming external partners.

Key Architecture Rule: Autonomous agents must treat multi-step tool execution as a distributed state machine. Every tool invocation must be governed by a Tri-State Execution Model (Confirmed Success, Confirmed Failure, Indeterminate), backed by client-side idempotency keys and structured Saga compensation protocols.

The Tri-State execution model: Why network timeouts are not failures

A foundational flaw in naive agent frameworks is treating every HTTP exception or socket timeout as a "confirmed failure." In distributed systems, network communication adheres to a Tri-State reality:

1. Confirmed Success: The destination system processed the request and successfully returned a verified response payload (e.g., HTTP 200 OK with a resource UUID).
2. Confirmed Failure: The destination system explicitly rejected the request prior to applying any state change (e.g., HTTP 400 Bad Request due to invalid schema, HTTP 403 Forbidden, or HTTP 404 Not Found).
3. Indeterminate Outcome (Unknown In-Flight State): The agent dispatched the request across the network, but the socket timed out, the connection dropped, or the gateway emitted an HTTP 504 Gateway Timeout before returning a receipt.

In the Indeterminate state, the agent cannot determine whether:

• The network dropped the packet before it reached the destination server (meaning zero changes occurred).
• The destination server received the payload, committed the transaction to its database, and crashed before transmitting the HTTP 200 response back across the wire.

The AWS Builders' Library reference on making retries safe with idempotent APIs explains how client-generated idempotency tokens allow distributed clients to safely retry indeterminate requests without risking duplicate mutations. If an agent blindly retries a non-idempotent $10,000 wire transfer request following an HTTP 504 timeout, it risks executing two independent transfers.

A worked failure scenario: The five-step enterprise project handoff

To understand how partial failure handling operates in practice, examine a concrete enterprise scenario: an autonomous IT service agent executing a multi-step project handoff workflow across four independent internal enterprise systems. The table below illustrates the state machine progression and recovery paths across each step. The values below are deliberately synthetic and illustrative; they do not represent proprietary customer data or benchmark claims.

In this scenario, Step 3 encounters an indeterminate gateway timeout.

The agent framework must immediately execute a deterministic recovery protocol:

1. Freeze Execution Graph: Halt progression to Steps 4 and 5.
2. Perform Reconciliation Query: Invoke a dedicated read-only verification probe querying the infrastructure API for any cluster possessing the unique correlation tag idempotency_key: prj-409.
3. Branch Based on Reconciliation:
   • If the cluster exists and is healthy: Capture its IP, mark Step 3 as Confirmed Success, and resume execution to Step 4.
   • If the cluster definitely does not exist: Re-dispatch the provisioning call using the identical idempotency token.
   • If the infrastructure API remains completely unreachable after three exponential backoff retries: Flag the task as BLOCKED_INDETERMINATE, persist the intermediate execution checkpoint, and alert the platform engineering team with an exact recovery payload.

Pro Tip: Never use natural language string matching (such as searching for a project title) to reconcile indeterminate state. In enterprise systems where users frequently create entities with identical display names, searching by string generates false-positive bindings. Reconcile state exclusively via immutable, deterministic idempotency keys generated before the first write attempt.

Codify operational recovery policies per tool behavior

Different tools exhibit fundamentally different mutation behaviors. A single monolithic retry loop cannot govern reads, updates, appends, and external messaging.

Engineering teams must categorize each tool in the agent's catalog according to its stateful behavior:

The table below outlines the recovery policies across standard enterprise tool archetypes.

Anthropic’s engineering guidance on writing tools for agents highlights the importance of providing tools with clear, structured return errors that explain why an operation failed, enabling the calling agent to adjust its execution parameters intelligently rather than repeating identical mistakes.

The limits of compensation: Why "undo" is often an architectural illusion

In distributed systems theory, the Saga Pattern manages multi-step transactions by executing compensating transactions when a step fails: if Step 3 fails, the orchestrator executes "Undo Step 2" and "Undo Step 1."

However, in enterprise business operations, true compensation is frequently impossible:

• Irreversible External Side-Effects: If Step 1 sent an email notification to 500 branch managers or executed a bank wire transfer, you cannot "un-send" the email or silently pull money back from an external bank.
• Cascading Downstream Dependencies: Between the time Step 2 created a JIRA ticket and Step 4 failed, an automated CI/CD pipeline may have already detected the ticket, allocated physical hardware, and begun building software artifacts. Deleting the ticket breaks downstream processes.
• Competing Human Edits: If an agent updates a database row at 10:00 AM, a human operator edits an adjacent column at 10:01 AM, and the agent attempts to "compensate" by rolling back the row at 10:02 AM, the agent silently obliterates the human's manual edits!

Before configuring automated compensation, determine whether the operation can be cleanly reversed. When compensation carries business risk, the agent must not guess: it must halt, preserve all verified state, and escalate to a human reviewer via structured approval interfaces, as detailed in our guide to human approval for AI agent actions.

An eight-stage agent partial failure recovery runbook

To ensure resilience in production, implement an eight-stage automated recovery harness within your agent orchestration runtime:

1. Emit Pre-Execution Checkpoint: Prior to invoking any mutating tool, persist the complete agent context, tool name, input arguments, and unique idempotency key to durable storage.
2. Execute with Bounded Timeouts: Enforce strict client-side timeouts on all external tool calls (e.g., 15-second connect timeout, 30-second read timeout).
3. Classify Result State: Categorize the response into Confirmed Success, Confirmed Failure, or Indeterminate.
4. Trigger Active State Reconciliation: If indeterminate, execute a read-only query using the idempotency key to determine if the target system committed the mutation.
5. Evaluate Retry Budget: If confirmed failed with a transient error (e.g., HTTP 429 Rate Limit or HTTP 503 Service Unavailable), retry using truncated exponential backoff with full jitter, capped at a maximum of three attempts.
6. Determine Forward vs. Backward Recovery: If retries exhaust, determine whether the workflow can achieve forward recovery (e.g., selecting an alternate API endpoint) or requires backward compensation.
7. Persist Execution Audit Trail: Write the complete execution graph, including all attempted retries, timeouts, and compensation outcomes, to the immutable AI agent action audit trail.
8. Synthesize Transparent User Status: Present the end user with a precise, transparent status update detailing exactly which steps succeeded, which step stalled, and what manual action is required. Never emit a generic "Task failed" error that obscures partial progress.

By enforcing these eight architectural gates, enterprise platform teams can deploy autonomous agents that execute multi-step workflows with complete operational integrity and robust error tolerance.

For comprehensive methodologies on evaluating agent reasoning and task completion reliability, consult our enterprise knowledge assistant evaluation guide.

To explore how our platform manages distributed tool execution, discover Exemplary AI enterprise agents and schedule an enterprise architecture demo to observe automated partial failure recovery and idempotency protocols in live enterprise workflows.