AI Agent Reliability: Designing Retries, Recovery, and Human Escalation

A failed response is not a failed operation. A successful response is not a successful operation either. Everything hard about AI agent reliability lives in that gap.

The moment that breaks most agent systems is not dramatic. A tool call goes out to a payment API, a ticketing system, or an internal workflow service. The call times out. The orchestrator now faces a question it cannot answer from the error message alone: did the downstream system execute the action, or did the request die before it arrived?

If the request never landed, retrying is safe. If it landed and only the response was lost, retrying creates a duplicate charge, a duplicate ticket, or a duplicate shipment. The model cannot resolve this by sounding confident. Confidence is not evidence about remote state.

This is the boundary where production agent engineering begins. Permissions and action boundaries decide what an agent is allowed to attempt; evaluation and monitoring decide whether it is behaving. Recovery design decides what happens when the attempt itself becomes ambiguous. That third layer is what this article covers.

Why Agent Failures Break Normal Retry Logic

Traditional reliability patterns still apply to agents: timeouts, retries, circuit breakers, idempotency, tracing, transactional state. None of that is new. What changes is where those patterns must be enforced.

In a conventional service, you place reliability controls around the service boundary. The service owns its database, its transaction semantics, and its failure modes. With agents, the side effects are scattered across every tool the agent can call. A single agent run might touch a search API, a CRM, a file store, and an email provider, each with different retry semantics and different notions of what "already happened" means. Reliability has to move down to the level of each side-effecting tool call, not sit at the outer edge of the request.

The second shift is the unknown-state problem. A timeout does not mean failure. It means the caller does not know the outcome. That distinction is the single most important reliability concept for production agents, and it is the one most often collapsed by retry code that treats any exception as a signal to try again.

Grant the narrow case where blind retry is fine. Read-only calls, pure lookups, and operations you can prove never executed are safe to repeat. The moment a call can mutate state, blind retry becomes a coin flip on duplicate execution.

It helps to stop treating "the agent failed" as one thing. Four failure classes get collapsed into that phrase, and they demand different responses:

• Model failure. The model produced a poor decision, a malformed tool call, or a hallucinated argument.
• Tool failure. The external system errored, returned garbage, or behaved outside its contract.
• State uncertainty. The system cannot determine whether the requested operation actually occurred.
• Business failure. The technical operation succeeded, but the intended outcome did not happen.

That last one is the quiet killer. A refund API returns 200. The refund posts to the wrong ledger. Every technical signal says success. The business outcome says otherwise. If your reliability definition stops at "the call returned 200," you will ship agents that are technically healthy and operationally wrong.

So reframe the goal. Reliability is not "the agent answered well." It is "the intended operation occurred exactly once, and we can prove it." Everything below is machinery for making that provable.

A Worked Failure Path

Before the mechanisms, walk one scenario end to end. It is the fastest way to see why the pieces exist and how they connect.

An agent is processing a customer refund. The workflow has four steps: validate the order, issue the refund through a payment API, update the CRM record, and send a confirmation email. The refund API is non-idempotent unless the caller supplies an idempotency key.

The agent validates the order and calls the refund API. The call times out after 30 seconds. The orchestrator has no response and no error code — only silence.

Here is what a naive system does: catch the timeout, retry the refund, and move on. If the first call actually landed, the customer is now refunded twice. The system has no way to know, because it never checked.

Here is what a recovery-aware system does, step by step:

1. Classify. The timeout is not a clean failure. It maps to unknown state, not transient timeout, because the call was non-idempotent and the outcome is unverifiable from the error alone.
2. Consult the ledger. The orchestrator recorded the attempt with an idempotency key before the call went out. The ledger shows the operation is in-flight with an unresolved outcome.
3. Verify. The orchestrator queries the payment API for the refund status using the idempotency key. The API returns the refund record: it landed. The operation succeeded; only the response was lost.
4. Reconcile. The ledger is updated to completed. The workflow resumes at step three — the CRM update — rather than restarting from the refund.
5. Checkpoint. If the CRM update then fails with a genuine transient error, the checkpoint ensures the resumed run knows the refund is already done and does not re-issue it.

Now change one variable. Suppose the verification call also times out, or the payment API has no status endpoint. The orchestrator cannot determine whether the refund landed. That is the escalation trigger: unknown state on a consequential action, with verification exhausted. The escalation payload carries the idempotency key, the attempted amount, the last known state, and the verification attempts that failed. A human resolves it in seconds instead of reconstructing the incident from logs.

One scenario, five mechanisms. The rest of this article explains each one and the decision boundaries between them.

Failure Semantics: Classifying Errors Before Acting

The recovery path should be chosen by evidence, not by the model's confidence. That means raw errors need to become categories before any retry logic runs.

A failure classifier maps incoming errors into operational categories. A workable starting taxonomy:

• Transient timeout. The call failed in a way that suggests a temporary condition.
• Unknown state. The call may or may not have executed.
• Authorization failure. The agent lacks permission, or credentials expired.
• Duplicate risk. The operation is non-idempotent and a prior attempt may have landed.
• Partial completion. A multi-step operation finished some steps and not others.

Each category implies a different permitted transition. Transient timeouts on read-only calls can retry. Unknown state must verify before retrying. Authorization failures escalate or abandon; retrying them just burns budget. Duplicate risk requires a state check against the downstream system. Partial completion requires reconciliation, not restart.

This is where tool contracts earn their keep. A production tool response should carry more than success or failure. It should describe retryability, side-effect risk, whether verification is required, and a business reference the orchestrator can use to check state later. A tool that returns {"status": "error"} and nothing else forces the orchestrator to guess, and guessing is how duplicate charges happen.

One more distinction matters: correctable transient errors versus persistent errors. A 503 from an overloaded service is transient. A 403 that keeps returning after credential refresh reflects a systematic blind spot — wrong scope, wrong environment, wrong assumption about the API. Retrying the second kind does not fix it. It converts a fast failure into a slow one and hides the real problem behind retry noise.

My rule for the classifier: if an error cannot be placed in a category, the default transition is verify or escalate, never retry. Unclassified errors are exactly the ones where you have the least information, and retrying from ignorance is how you turn one incident into two.

Idempotency as a Reasoning Boundary

Idempotency means an operation can be repeated without changing the outcome beyond the first execution. It is the property that makes "did this already happen?" answerable.

The critical design decision is where that answer lives. If the model is trusted to infer whether an action already occurred, you have built reliability on top of a system that cannot observe remote state. The model does not know whether the payment landed. It only knows what its context says.

Move the decision into code. Two mechanisms do most of the work:

Idempotency keys. The orchestrator generates a unique key per intended operation and passes it to the tool. The downstream system uses the key to deduplicate. A retry with the same key is safe because the system recognizes it as the same logical operation, not a new one.

An action ledger. A durable, application-owned record of attempted operations: idempotency keys, side-effect state, verification results, and recovery status. The ledger is what makes recovery auditable. When an incident review asks "what did the agent actually do at 14:32?", the ledger answers without archaeology.

Idempotency is a boundary, not a behavior. It tells the orchestrator whether repeating an action is safe, and that decision should be visible in code where you can test it, not hidden in model behavior where you can only hope for it.

Where idempotency is impossible, the design has to change shape. Some external APIs have no deduplication. Some actions are irreversible by nature — sending an email, publishing a post, transferring funds to an external account. For those, retry is off the table. The recovery path shifts to pre-commit verification and human approval: check state before acting, and require a human decision when the action cannot be safely repeated.

There is a cost tradeoff here, and it is worth being honest about it. Durable ledgers, verification calls, and idempotency key management add latency and infrastructure. Scoping them to consequential actions — anything that moves money, changes customer-visible state, or touches external systems — keeps the overhead where it buys real safety. Wrapping every read-only lookup in a ledger is ceremony, not reliability.

Checkpoints, Recovery Paths, and Bounded Retries

Retry should be one transition in a controlled recovery state machine, not the default response to any error. The state machine has a small number of states and a small number of transitions, and every transition is chosen by the classifier.

Bounded retries need explicit limits on four dimensions:

• Attempt count. How many times before the system stops trying.
• Backoff. How long between attempts, ideally with jitter to avoid synchronized retry storms.
• Total time budget. A wall-clock ceiling for the whole recovery attempt, not just per-call.
• Terminal state. What happens when the bounds are exhausted. It must hand off, not loop.

That terminal state is the part teams skip. A retry loop without a terminal state is a system that will eventually retry forever, or until something upstream kills it. Neither is a recovery path.

Checkpoints address a different failure: resuming a multi-step task without re-executing completed side effects. A checkpoint persists enough task state that a resumed run knows which steps finished, which are in flight, and which never started. Without checkpoints, a resumed agent re-runs from the beginning, and every non-idempotent step in the completed portion becomes a duplicate risk.

Partial completion deserves first-class status. Real workflows fail in the middle. Three of five steps succeeded, the fourth timed out, and the fifth never ran. The recovery path must reconcile the completed steps against the intended outcome rather than restart the whole task. Reconciliation means querying the downstream systems for actual state, comparing it to the plan, and executing only the delta.

Verification-before-retry is the operational form of everything above. Before issuing a second attempt, query the downstream system for the operation's actual state. If the operation landed, mark it complete and move on. If it did not, retry with the same idempotency key. If the state cannot be determined, escalate.

The failure mode to watch for is the retry storm. When multiple agents or multiple steps share a non-idempotent action, one slow dependency can trigger cascading re-execution across the whole system. Each agent retries independently, each retry looks locally reasonable, and the downstream system receives a flood of duplicate operations. Bounded retries with jitter and a shared ledger that records in-flight operations are the defense. Without them, the retry logic becomes the outage.

The Decision Boundary: Retry, Verify, Reconcile, or Escalate

The mechanisms above collapse into one decision you will make on every failed call. Make it explicit, because the wrong transition is where duplicates and lost work come from.

The boundary between verify and escalate is the one that matters most. Verify is available when the downstream system exposes a way to check state — a status endpoint, a query by idempotency key, a read-back of the affected record. Escalate is the answer when that check does not exist or does not resolve the question. The distinction is not about how hard the problem feels. It is about whether the system has a mechanism to observe the truth.

The boundary between retry and reconcile is subtler. Retry re-issues one operation. Reconcile re-examines a whole task against its intended outcome. If a workflow has more than one side effect, and any of them may have landed, you are in reconcile territory, not retry territory.

Human Escalation: When Autonomy Should Stop

Escalation is not a fallback for anything the agent finds hard. It is a risk-driven transition with explicit triggers, and it should fire on uncertainty and consequence, not on difficulty.

Workable escalation triggers:

• Unknown state on a consequential action.
• Authorization failures that survive credential refresh.
• Duplicate risk where verification cannot resolve the ambiguity.
• Repeated bounded-retry exhaustion.
• Any action the classifier cannot categorize.

Notice what is not on the list: "the model is unsure." Model uncertainty is a weak signal because it is not calibrated to actual risk. A model can be confidently wrong about a payment and hesitantly correct about a log query. Escalation triggers should be tied to observable system state, not to the model's self-report.

Escalation needs a payload, not just a ping. A useful escalation tells the human what was attempted, the current known state, the evidence that supports it, the options the system considered and rejected, and a recommended next action. "Agent needs help" is not an escalation. It is a ticket that starts an investigation from zero.

This is where transparency beats black-box automation. An agent that can explain why it acted, what it declined to do, and which options it rejected gives the human a decision to make rather than a mystery to solve. The operational standard worth borrowing from mature infrastructure teams is simple: require agents to reason about why and how they performed an action, and prefer transparency over opaque automation. That standard applies whether your agent runs a payment workflow or a log query.

Placement matters too. Pre-action approval gates and post-failure review have different profiles. A pre-action gate adds latency to every gated operation but catches problems before they touch state. A post-failure review is faster in the common case but only helps after something has already gone wrong. The right split depends on the action: irreversible or high-blast-radius operations justify pre-action gates; recoverable operations can use post-failure review.

Escalation paths need owners, service-level expectations, and a feedback loop. When a human resolves an escalation, the resolution should feed back into the classifier and into regression tests. An escalation that gets resolved and forgotten is a failure mode that will repeat.

Observability and Evaluation for Recovery Paths

Recovery decisions must be traceable. When an incident review asks why the agent retried instead of escalating, the answer should be in the trace: which classifier category fired, which transition was chosen, and what evidence supported it. If the trace only shows the final answer, you cannot reconstruct the decision, and you cannot improve it.

This connects to evaluation in a specific way. Standard evaluation compresses agent behavior into a single success score, and that score hides exactly the properties recovery design cares about. A research paper on agent reliability metrics makes the point directly: rising accuracy on benchmarks does not capture whether agents behave consistently across runs, withstand perturbations, fail predictably, or have bounded error severity. Treat that as a research signal rather than a settled field-wide fact, but the implication for builders is concrete: a high task-success number is not evidence that your recovery paths work.

Evaluation for recovery should measure dimensions a single score misses:

• Consistency. Does the agent behave the same way across repeated runs of the same task?
• Robustness. Does it hold up when inputs are perturbed or dependencies degrade?
• Predictability of failure. When it fails, does it fail in recognizable, classifiable ways?
• Bounded error severity. When something goes wrong, is the damage contained?

The practical move is to replay known failure scenarios in CI. Timeouts, duplicate risk, partial completion, authorization failures — each should have a test that exercises the recovery path and asserts the chosen transition. Failure scenarios tested only in production are failure scenarios you learn about from customers.

This section assumes your evaluation and monitoring setup already exists. What recovery design adds to it is a specific requirement: the trace must capture the decision, not just the outcome.

A Practical Checklist for Reliable Agent Recovery

Convert the mechanisms above into ordered decisions you can apply to an existing workflow:

1. Inventory side-effecting tool calls. Mark each one idempotent, conditionally idempotent, or non-idempotent. This inventory is the foundation; everything else depends on knowing which calls can be safely repeated.
2. Define the failure taxonomy and permitted transitions. Write down the categories and what each one allows — retry, verify-then-retry, escalate, or abandon — before writing retry code.
3. Add a durable action ledger with idempotency keys for consequential operations. Scope it to actions that move money, change customer-visible state, or touch external systems.
4. Set explicit retry bounds and a terminal escalation state. Attempt count, backoff with jitter, total time budget, and a defined handoff when bounds are exhausted.
5. Make verify the default when state is unknown. If the system cannot determine whether an operation executed, it verifies or escalates. It does not retry.
6. Write the escalation payload contract. Define what an escalation must contain and assign an owner for each escalation class.
7. Add failure-scenario regression tests to CI. Replay timeouts, duplicate risk, and partial completion as automated tests.
8. Review classifier accuracy after real incidents. When an error lands in the wrong category, fix the classifier, not just the incident.

What to Watch

Two open questions will shape how builders design recovery over the next few years.

Will tool protocols standardize operational semantics? Today, each integration defines its own contract for retryability, side-effect risk, and verification hints. If protocols converge on standard operational semantics, recovery logic becomes portable across tools. If they do not, every integration remains a custom contract, and the classifier stays coupled to each tool's quirks. This is the single highest-leverage standardization question for recovery design, because it determines whether the classifier is reusable infrastructure or per-tool glue.

Where does recovery live — orchestrator or tool? Some recovery logic belongs in the orchestrator, which sees the whole task. Some belongs in the tool, which knows its own semantics. The split affects portability: recovery logic in the orchestrator travels across frameworks; recovery logic in the tool ties you to that tool. Watch how the boundary settles as tool contracts mature.

The reason to invest here is that reliability work compounds. A classifier, a ledger, and an escalation contract built once become reusable infrastructure across every agent you ship. The first agent pays the cost. The tenth agent inherits the safety.

When state is unknown, verify before you retry. When verification is impossible or the action is consequential, escalate. That rule will not cover every case, but it covers the ones that produce duplicate charges, lost tickets, and incident reviews that start with "we're not sure what happened."