Agent Engineering Digest KB

Error Handling and Retries in Agentic Systems

Error handling and retries in agentic systems are the controls that decide what happens when an AI agent cannot complete a step correctly. The failure may come from a tool, a model output, missing context, a validation check, a policy violation, or an external system.

Retries can make agent systems more reliable, but uncontrolled retries can make them more dangerous. A production agent should know when to retry, when to change strategy, when to stop, when to ask for help, and when to roll back a state-changing action.

Short Answer

Agentic systems should handle errors by classifying the failure, recording it in workflow state, applying a bounded retry policy only when safe, validating the result, and falling back or escalating when the retry limit is reached.

Good retry design includes:

  • error classification
  • retry limits
  • exponential backoff
  • idempotency keys
  • validation after retry
  • fallback paths
  • human escalation
  • rollback or compensation for side effects
  • logs and traces for debugging

Why Agent Errors Are Different

Traditional software errors often happen at fixed points in deterministic code. Agent errors can happen inside a dynamic loop.

An agent may choose tools, revise plans, interpret tool outputs, retrieve context, generate answers, or decide that it is finished. Each decision creates another place where failure can enter the system.

This is why agentic error handling needs workflow-level control, not just a generic try-catch block.

Common Error Types

Agentic systems commonly encounter several classes of errors.

  • Transient errors: timeouts, network failures, rate limits, temporary service outages.
  • Tool errors: invalid inputs, permission failures, unavailable APIs, malformed responses.
  • Retrieval errors: missing documents, irrelevant results, stale context, permission-filter mismatches.
  • Model output errors: hallucinations, invalid JSON, incomplete answers, unsafe instructions.
  • Planning errors: impossible tasks, wrong tool sequence, circular plans, missing prerequisites.
  • Validation errors: failed schema checks, failed factuality checks, failed policy checks.
  • State errors: duplicate actions, invalid state transitions, lost checkpoints, stale approvals.

Classify Before Retrying

The first rule is simple: do not retry every error.

Some errors are likely to succeed on retry. Others need different inputs, a different tool, human review, or a clean failure response.

For example, a network timeout may be retried. A permission denial should usually not be retried by the agent. A validation failure may need a corrected prompt or additional retrieval. A missing required field may need clarification from the user.

Retryable vs Non-Retryable Errors

Retryable errors are usually temporary.

  • rate limits
  • network timeouts
  • temporary service unavailability
  • lock conflicts
  • background job delays

Non-retryable errors usually require a different path.

  • invalid credentials
  • permission denied
  • missing required data
  • unsafe request
  • schema mismatch
  • unsupported task
  • user cancellation

Some errors are conditionally retryable. A malformed model output can be retried with stricter formatting instructions, but only a small number of times.

Bounded Retries

Every retry loop should have a limit.

Useful retry controls include:

  • maximum attempts
  • maximum total time
  • backoff delay
  • jitter to avoid synchronized retries
  • stop conditions
  • fallback behavior after failure

Bounded retries prevent agents from burning tokens, repeating the same mistake, or creating operational load during outages.

Exponential Backoff

Exponential backoff increases the delay between retries.

attempt 1: wait 1 second
attempt 2: wait 2 seconds
attempt 3: wait 4 seconds
attempt 4: wait 8 seconds

This is useful for transient infrastructure errors because it gives overloaded systems time to recover.

Backoff is not a fix for bad inputs. If the agent sends the wrong tool arguments, waiting longer will not help.

Idempotency

Idempotency means a retried action does not create duplicate side effects.

This matters whenever an agent calls a write tool.

Examples:

  • creating a ticket
  • sending an email
  • charging a customer
  • updating a database record
  • triggering a deployment

Use idempotency keys, external IDs, or deduplication checks so a retry does not repeat the action.

Tool Error Handling

Tool errors should be structured.

A tool should return enough information for the orchestrator to decide what to do next:

  • error type
  • error message
  • whether retry is allowed
  • whether the action changed external state
  • recommended next action
  • correlation ID for debugging

Do not expose raw internal errors directly to the model if they contain secrets or sensitive operational details.

Model Output Errors

Models can produce invalid, incomplete, or unsupported outputs.

Common examples include malformed JSON, missing fields, unsupported tool names, hallucinated citations, or answers that fail a policy check.

Handle these with output validation, repair prompts, constrained schemas, and limited correction attempts.

Validation Feedback Loops

A validation feedback loop scores an output, gives corrective feedback, and retries the step.

For example, if an answer fails a grounding check, the next attempt may include stricter instructions to use only retrieved evidence. If a response is too verbose, the retry may include a concise format requirement.

The loop should stop after a small number of attempts. If the output still fails, escalate or return a safe fallback.

Impossible Tasks

Some tasks cannot be completed with the available tools or data.

An agent should be able to mark a task as impossible instead of retrying forever.

Examples:

  • the user asks about data the system cannot access
  • the required tool is not available
  • retrieval returns no relevant evidence
  • a policy blocks the requested action
  • required approval is denied

Recognizing impossibility is a reliability feature.

Fallback Paths

A fallback path defines what happens after retries fail.

Fallbacks may include:

  • asking a clarifying question
  • returning a partial answer with limitations
  • using a safer deterministic response
  • routing to a human
  • pausing the workflow
  • creating a support ticket
  • canceling the workflow

The fallback should be explicit, not improvised after the agent gets stuck.

Circuit Breakers

A circuit breaker stops repeated calls to a failing dependency.

If a tool or service is failing repeatedly, the system can temporarily block new calls and route workflows to a waiting or fallback state.

This protects external systems, reduces noisy failures, and prevents agents from amplifying an outage.

Rollback and Compensation

Retries are not enough when an agent has already changed external state.

If an agent performs a harmful or incorrect action, the system may need rollback or compensation.

  • Rollback restores a previous state.
  • Compensation performs a new action that corrects the previous action.

For example, a bad configuration update may be rolled back. A wrongly sent message may need a correction message. A wrong transaction may need a compensating transaction.

Human Escalation

Not every error should be solved automatically.

Escalate when:

  • the action is high risk
  • the agent lacks enough evidence
  • the same validation fails repeatedly
  • a policy decision is ambiguous
  • a rollback may affect users
  • the workflow reaches its retry limit

Human escalation should preserve the workflow state so the reviewer can see what happened.

Error State

Error handling depends on state management.

Store:

  • current workflow step
  • error type
  • error message or safe summary
  • retry count
  • last retry time
  • tool inputs and outputs
  • validation results
  • fallback decision
  • human review status

Without error state, the system cannot reliably resume, debug, or audit the workflow.

Observability

Agent errors need traces, not just logs.

A trace should show the original request, selected plan, retrieved context, tool calls, validation results, retries, state transitions, and final outcome.

This helps teams answer the important question: did the agent fail because the model reasoned poorly, the tool failed, the context was wrong, the validation was too strict, or the workflow design was incomplete?

Security Considerations

Error handling can leak information if implemented carelessly.

Avoid passing secrets, stack traces, private data, or internal service details into model-visible error messages. Sanitize tool errors before they become part of the agent context.

Also avoid retries that bypass permission checks. Every retry should enforce the same access control as the first attempt.

Evaluation

Evaluate error handling by testing failure paths, not just happy paths.

Useful tests include:

  • tool timeout
  • rate limit
  • malformed tool output
  • invalid model JSON
  • missing retrieval evidence
  • failed validation
  • permission denial
  • duplicate retry risk
  • human approval rejection
  • rollback failure

A reliable agent should behave predictably under all of these conditions.

Common Mistakes

  • Retrying every error without classification.
  • Letting the agent decide retry limits dynamically.
  • Retrying write actions without idempotency.
  • Hiding errors instead of recording them in state.
  • Passing raw stack traces into the model context.
  • Failing to stop after repeated validation failures.
  • Not distinguishing impossible tasks from temporary failures.
  • Skipping rollback planning for state-changing tools.

Design Checklist

  • Classify errors before choosing a response.
  • Retry only transient or correctable failures.
  • Use bounded retries with backoff and stop conditions.
  • Make write actions idempotent where possible.
  • Validate outputs after retries.
  • Add fallback and escalation paths.
  • Use circuit breakers for failing dependencies.
  • Store retry and error state durably.
  • Plan rollback or compensation for side effects.
  • Trace every retry decision for debugging and audit.

Summary

Error handling in agentic systems is about controlled recovery. The system should understand what failed, decide whether retrying is safe, limit retry attempts, validate corrected outputs, and stop when the task is impossible or risky.

Retries are useful for transient failures and correctable model outputs. They are dangerous when applied blindly to write actions, permission failures, policy violations, or impossible tasks. Production agents need structured errors, durable state, idempotency, fallback paths, observability, and rollback planning.