AI Agent Reliability Engineering: SLOs, Retries, Checkpoints, and Recovery

An AI agent is reliable when it consistently completes the intended task, respects its authorization and safety boundaries, and handles partial failures without duplicating actions or inventing success. An HTTP 200 response is not enough. A service can be available while an agent silently makes a wrong decision, acts twice, or tells a user an action succeeded when the system of record disagrees.

For production, reliability is a property of the entire workflow: models, prompts, tools, data, execution state, approval decisions, network dependencies, and operating controls. The practical design is to define task-level objectives, make actions replay-safe, classify failures, use bounded recovery, record state and evidence, and verify the business outcome.

Quick answer: Start with a task-level SLO and a clear success predicate. Enforce timeouts and a retry budget, use idempotency keys for side-effecting tools, checkpoint workflow state, restrict fallback to policy-approved routes, and prove recovery through fault-injection tests. When the result of an external action is uncertain, reconcile it before retrying.

What makes AI agent reliability different?

Traditional distributed systems already have partial failure, timeouts, concurrency, and non-idempotent operations. Agents add semantic failure: they may receive technically valid information, misunderstand it, choose an unsuitable tool, or compensate for missing evidence with a plausible-sounding assertion.

Consider an invoice-processing agent:

1. It retrieves an invoice and an approval record.
2. It calls create_payment.
3. The payment service times out after committing the payment.
4. The agent interprets the timeout as failure and calls the tool again.
5. The user sees a success message, but two payments exist.

A model retry cannot fix this architectural defect. The workflow needs a stable action identifier, a system-of-record reconciliation step, and an execution engine that distinguishes requested, attempted, confirmed, and unknown action states.

A second example is a research agent whose retrieval service returns old evidence with HTTP 200. Infrastructure monitoring sees success; the decision is still wrong. This is why agent evaluation and agent observability must connect to reliability engineering, but do not replace it.

Design a reliability contract before building recovery logic

Set objectives against the consumer's task, not the number of completed LLM calls. Define a good task as one that reaches a verified outcome, stays within policy, and completes within an acceptable time window.

The targets are examples. For a financial transaction agent, one incorrect payment may be unacceptable regardless of a strong average completion score. For a low-risk content assistant, delayed service may be a tolerable degradation.

Compute error budgets on the right denominator. If the target is 99% good tasks in a four-week window, the budget is 1% of eligible tasks: not 1% of model calls. Segment by risk tier, tool, tenant, model version, and workflow. Google's SRE guidance on SLOs and error budgets emphasizes indicators tied to user experience and explicit error-budget policies.

Reference architecture for a reliable agent

User / Event
     |
     v
Task contract + identity + risk tier
     |
     v
Durable workflow / state machine <----> Checkpoint store
     |
     +--> Planner / model calls -------> Model gateway
     |
     +--> Tool dispatcher ------------> Allowed tools / APIs
     |          |                            |
     |          +--> idempotency ledger      +--> system of record
     |
     +--> Policy + approval gate ------> Human reviewer
     |
     +--> Outcome verifier ------------> authoritative state
     |
     +--> Trace, metrics, audit -------> Monitoring / evaluation
     |
     v
Verified result OR explicit escalation

Do not allow a model to be the source of truth for whether its action succeeded. The tool dispatcher validates arguments, authorization, concurrency, and action identity. The outcome verifier checks the authoritative system. The workflow engine owns state transitions and recovery, while the model proposes plans or tool calls inside those boundaries.

Classify failures before deciding what to retry

This table is a starting policy; actual retryability depends on each API contract. An HTTP status alone cannot prove whether a side effect occurred.

The existing DataKnobs agent tool integration guide explains tool exposure and permission boundaries. At the reliability layer, every state-changing tool should additionally document its deduplication and reconciliation behavior.

Use retries, backoff, and jitter without creating a retry storm

For safe-to-retry operations, use a fixed maximum attempt count, a total deadline, capped exponential backoff, and jitter. Repeated requests should be retried at one designated layer rather than independently across a chain of services. The AWS Builders' Library guidance explains how retries can amplify overloaded dependencies and why side effects need idempotent APIs.

This pseudocode illustrates the decision boundary: not a drop-in client library:

async def execute_with_retry(call, classify, deadline, max_attempts=3):
    for attempt in range(max_attempts):
        if monotonic() >= deadline:
            raise DeadlineExceeded()
        try:
            return await call()
        except Exception as exc:
            decision = classify(exc)
            if decision != "RETRYABLE" or attempt == max_attempts - 1:
                raise
            delay = min(2 ** attempt, 8) * uniform(0.5, 1.0)
            await sleep(min(delay, max(0, deadline - monotonic())))

Keep model-call retry separate from business-action retry. Retrying a failed inference may yield different text or plans; repeating a payment, deletion, or message requires an action-level guarantee. Use provider idempotency features when available and test their documented scope and expiration.

Idempotency and reconciliation protect real-world actions

An idempotent business action produces the intended side effect once even if the caller submits the same action more than once. It does not mean the model will produce identical wording or reasoning on every run.

Before execution, the application creates a stable action_id and records the authorized intent. It must reuse the same identifier for retries of that intent, rather than generate a new identifier for each model attempt.

{
  "workflow_id": "wf_7b9",
  "action_id": "act_2026_1042",
  "action_type": "issue_refund",
  "entity_id": "order_1042",
  "amount_minor_units": 5000,
  "currency": "USD",
  "authorization_version": "approval_3",
  "state": "REQUESTED"
}

Use a database uniqueness constraint on (tenant_id, action_id) and an outbox or comparable transactional handoff. The downstream tool should accept an idempotency key if its API supports one. After a timeout, fetch the operation status from the system of record using the action or provider reference. If the outcome is still unknown, mark UNKNOWN / NEEDS_RECONCILIATION and stop automated replay.

Do not promise exactly-once external effects merely because the orchestration framework persists state. End-to-end correctness depends on the downstream service's API and deduplication semantics. AWS's retry-with-backoff guidance similarly notes the necessity of idempotent operations when retrying.

Checkpoint workflow state and resume safely

A reliable agent needs to resume work after crashes, approvals, tool failures, and long waits. Save the workflow state at meaningful boundaries, including:

• workflow and task IDs, tenant, actor, permissions, and policy version;
• current step, tool input hash, action IDs, and attempt counters;
• external operation reference and last confirmed outcome;
• approval decision, reviewer, and expiration;
• deadlines, budgets, trace IDs, and safe-to-replay markers.

A simple state machine is:

NEW -> PLANNING -> READY_TO_ACT -> AWAITING_APPROVAL
                                |              |
                                |              v
                                |          APPROVED
                                v              |
                             EXECUTING <-------+
                                |
                  +-------------+-------------+
                  v             v             v
              CONFIRMED      UNKNOWN        FAILED
                  |             |             |
                  v             v             v
               VERIFY       RECONCILE     ESCALATE
                  |
                  v
              COMPLETED

A checkpoint is not proof that an external action succeeded. Save a durable operation reference and verify the external outcome after recovery. LangGraph documents checkpointers and persistence for recovery, interrupts, and workflow continuity; use persistent storage rather than an in-memory checkpointer for production durability.

Circuit breakers and fallback routes need policy constraints

A circuit breaker isolates an unhealthy dependency using closed, open, and half-open states. A repeated timeout or high failure rate can open it; controlled probes determine when the route may recover. A breaker protects the dependency and limits wasted attempts. A separate agent policy must prevent semantic improvisation when the dependency is unavailable.

Fallback should be explicit:

1. Try the approved primary provider or tool.
2. If the failure is eligible, route to an approved alternative with equivalent authorization, schema, and data-residency properties.
3. If no compliant alternative exists, return a limited answer or an actionable escalation: not fabricated data.

For example, a public FAQ agent might use a vetted cached answer, labeled with its freshness. A payment agent must not swap to a cached transaction outcome. Model fallback is acceptable only when the model's capabilities and output contract match the workflow's requirements.

A circuit breaker is optional, not a universal requirement: it adds operating modes and recovery complexity. Compare it with simpler bounded retry budgets and load-shedding before adoption. AWS's retry guidance discusses the trade-offs.

Human approval is a safety mechanism, not a cleanup step

Some failures should lead directly to a reviewer instead of another automated attempt: ambiguous payments, irreversible deletions, unauthorized access, conflicting authoritative data, or unresolved policy decisions. A human-in-the-loop boundary needs a specific reviewer, an expiration, a complete evidence package, and a durable resume path.

The OpenAI Agents SDK documents pause-and-resume approvals that surface interruptions and continue from saved run state. Regardless of SDK, authorization must be checked again on resume if permissions, amounts, or underlying records have changed.

For implementation patterns and reviewer UX, see human-in-the-loop design for AI agents.

Multi-agent reliability requires shared budgets and ownership

An agent handoff can multiply failure modes: unclear task ownership, stale shared context, circular delegation, duplicate execution, and hidden costs. For every delegated task, pass a correlation ID, parent workflow ID, deadline, remaining step budget, allowed tools, risk tier, and expected return contract.

The orchestrator: not each sub-agent independently: should own terminal task state and escalation. Enforce maximum handoff depth, prohibit cyclic delegation unless explicitly designed, and give only one component authority to commit a state-changing action.

The goal is not to make every agent independent. It is to prevent one failed specialist from losing the entire workflow or bypassing controls.

Instrument agent reliability as an operational discipline

Link model/tool traces to authoritative business results. Record at least:

workflow_id, trace_id, tenant_id, agent_version, policy_version
step_name, tool_name, provider, request_id, action_id
attempt_count, retry_reason, fallback_route, breaker_state
checkpoint_id, approval_id, outcome_status, verified_at
latency_ms, token_count, cost, deadline_remaining_ms

Protect sensitive prompt content; telemetry does not imply unrestricted retention. The dedicated AI agent observability guide covers instrumentation depth. Here, the reliability-specific dashboards should show good task rate, unverified side effects, recovery success by fault class, retry amplification, fallback policy compliance, P95 completion latency, and cost per verified task.

Create a pager condition for critical duplicate side effects or policy breaches even when aggregate success remains high. For volume-based reliability, use an error-budget burn-rate policy and segment by important customer journey. Avoid alerting on every single model 5xx if the workflow recovers safely and the user experience remains within SLO.

Chaos and fault-injection tests for agents

Do not assume that a retry, checkpoint, or fallback works simply because it is configured. Use an isolated test environment and inject failures deliberately.

Define a hypothesis, blast-radius limit, and abort condition for each experiment. A test passes only if the business invariant holds: not merely because the workflow returned a response. Convert production incidents into permanent regression cases, connecting the reliability program to agent testing and evaluation.

Example: resilient supplier-risk investigation agent

Imagine an enterprise agent that checks supplier sanctions data, recent financial news, and a procurement record before recommending review or approval.

Failure scenario: The sanctions service times out. The news service succeeds and the model attempts to infer the missing sanctions result from unrelated articles.

Reliability design: The sanctions signal is declared a required dependency for final approval. The dispatcher retries only the safe read request within a deadline. If the service remains unavailable, the workflow records SANCTIONS_CHECK_UNAVAILABLE, retains the retrieved evidence, and routes the case for human review. It must not mark the supplier approved.

Verification: An independent rule checks that no approval event exists unless a current sanctions result and required policy decisions are present. The agent may still produce a helpful status summary: “The investigation is incomplete; approval is blocked pending the sanctions check.”

This illustrates a vital distinction: graceful degradation does not mean pretending the workflow succeeded. It means preserving safe, useful behavior when the full task cannot be completed.

Example reliability policy contract

Put control values in configuration so they can be reviewed and tested, rather than burying them in prompts:

workflow: supplier_risk_review
version: 3
risk_tier: high
slo:
  verified_success_rate: 0.99
  max_completion_seconds: 30
budgets:
  max_model_calls: 8
  max_tool_calls: 12
  max_attempts_per_safe_read: 3
  total_deadline_seconds: 60
actions:
  approve_supplier:
    human_approval_required: true
    idempotency_required: true
    verify_system_of_record: true
failures:
  sanctions_service_unavailable: escalate
  authorization_denied: stop_and_audit
  stale_required_evidence: request_fresh_evidence
fallback:
  allowed_models: [approved_model_primary, approved_model_secondary]
  allow_unapproved_regions: false

These thresholds are illustrative. The real system must validate this policy schema, enforce it in code, and version every change.

A 30-day implementation plan

Week 1 : Contracts and failure inventory. Select one consequential agent; identify user-visible success, high-risk actions, dependencies, SLOs, and unknown-outcome cases. Remove speculative reliability statistics from documentation.

Week 2 : Durable execution and safety. Introduce workflow IDs, action IDs, checkpointing, deadlines, idempotency, authorization rechecks, and reconciliation. Test the timeout-after-commit scenario first.

Week 3 : Recovery paths. Add classified retries, rate limiting, fallback eligibility, human approval, safe-stop behavior, and a dead-letter or incident queue for unresolved work. Exercise each branch.

Week 4 : Release gates and operations. Instrument traces and business outcomes; run fault-injection tests; build a staged rollout and rollback; establish on-call ownership. Add regression tests from every high-severity failure.

Link the rollout to agent deployment and canary releases and agent operations and incident response. Reliability is not finished when the workflow launches; it is maintained through controlled changes and post-incident learning.

Frequently asked questions

What is AI agent reliability engineering?

It is the discipline of making AI agents consistently achieve verified business outcomes while recovering safely from model, tool, data, network, and workflow failures. It includes SLOs, idempotent actions, durable state, retry policies, fallback, human escalation, monitoring, and fault testing.

What is the difference between agent reliability and agent evaluation?

Evaluation measures whether an agent's behavior and outcome meet expected criteria, often in test datasets and trace grading. Reliability engineering uses those signals to design, operate, and recover real production workflows within service and safety objectives.

Can I simply retry a failed AI agent task?

Only when replay is safe. Retrying a model call may change the plan, and an external action may already have occurred before a timeout. For side-effecting operations, use a stable idempotency key and reconcile the authoritative outcome before retrying.

What SLOs are useful for enterprise AI agents?

Start with verified task completion, policy-safe execution, completion within a defined time, duplicate side-effect rate, recovery success, and cost per verified outcome. Use thresholds appropriate to the workflow's risk and consumer impact.

When should an AI agent escalate to a human?

Escalate when a required source is unavailable, an external action's outcome is uncertain, permissions have changed, evidence is contradictory, or a high-impact action requires approval. Preserve enough state and evidence for the reviewer to make an informed decision and resume safely.

Does checkpointing guarantee exactly-once tool execution?

No. Checkpointing preserves orchestration progress, but exactly-once business effects also depend on the downstream API, deduplication keys, transaction boundaries, and reconciliation. A workflow may resume successfully yet still duplicate an external action if those safeguards are missing.

Conclusion

Reliable AI agents do more than recover from HTTP errors. They must handle semantic uncertainty, tool side effects, distributed state, and policy constraints while protecting the real-world outcome. Start with a task-level contract, require verifiable completion, and design recovery around classify → contain → reconcile → resume or escalate → learn.

Treat retry counts, timeouts, fallback rules, autonomy limits, and evidence thresholds as versioned operating controls. DataKnobs KNOBS provides a fitting control-plane context for observing, evaluating, and tuning those variables against task success, cost, latency, and risk.

Sources

• Google SRE Workbook : Implementing SLOs
• AWS Builders' Library : Timeouts, retries, and backoff with jitter
• AWS Prescriptive Guidance : Retry with backoff
• LangGraph : Persistence and checkpointers
• OpenAI Agents SDK : Human-in-the-loop