AI Agent Error Handling in Production: The Complete Guide
It was 2:47 AM on a Tuesday when my phone started vibrating. SIVARO's lead gen agent had gone rogue. Not in a "made a slightly off-color joke" way. In a "spent $4,300 on API credits in eleven minutes hallucinating a perfectly formatted but completely fabricated data enrichment pipeline" way.
The agent had an error. It couldn't reach the enrichments API. And instead of failing gracefully, it retried. Aggressively. Each retry generated new context. Each new context generated new hallucinations. Each hallucination triggered more API calls.
We built that agent. We tested it extensively. For two weeks, it performed beautifully in staging. It passed every evaluation we threw at it. And it still melted down in production within two hours of deployment.
Here's the uncomfortable truth about ai agent error handling in production: most errors aren't where you think they are. The code is fine. The model is fine. The prompt is fine. The problem is the gap between what you tested and what production actually looks like.
This guide is everything I've learned about error handling for production AI agents after watching that 2:47 AM crash. From the fundamental differences between dev and prod, to the observability tools you actually need, to the specific retry strategies that prevent cascading failures.
Let's get into it.
The Production Divide: Why Agents Break in the Real World
We need to talk about the elephant in the room.
ai agents in production vs development differences aren't subtle. They're chasms. Google's own research on agentic infrastructure deployment highlighted five major hurdles, and error handling sat right at the center of all of them. The paper, which came out of studying real production deployments, found that the biggest time sinks weren't model quality — they were infrastructure failures. Rate limits. Timeouts. Schema mismatches. Data races.
In development, you're working with curated datasets and forgiving test cases. Your agent calls an API, gets a response, everyone's happy. In production, the API is down. The response is malformed. The third-party service changed its schema at 3:00 AM and didn't tell you. The database connection dropped. The model returned JSON with a trailing comma.
The core issue? Development tests for success. Production punishes you for every failure you didn't anticipate.
The Three Error Classes You'll Actually Face
Not all errors are created equal. After running production agents for years, I separate them into three buckets:
Deterministic errors — Timeouts, HTTP 429s, 500s, database connection failures. These are predictable. They're annoying, but they're solvable. Retry logic, circuit breakers, backoff strategies. You can engineer these away.
Semantic errors — The agent finishes its task successfully — but the output is wrong. The code compiles. The test passes. The JSON parses. But the answer doesn't match the user's intent. These are insidious because they don't look like failures. No alert triggers. No one notices until a customer does.
Escape hatches — The hardest class. Your guardrails were insufficient. The agent found a prompt injection. The "stop" keyword didn't work. It started calling external functions you never intended it to call. These are where 2:47 AM catastrophes live.
For deterministic errors, you need robust infrastructure. For semantic errors, you need evaluation pipelines. For escape hatches, you need to redesign your entire trust boundary.
Guardrails: Your First Line of Defense
Before we talk about error recovery, let's talk about error prevention.
The Anthropic engineering team published a guide on Building Effective AI Agents that made a point I've been circling for a while: the most reliable agent architectures are simple. They quote Genesys, who said they drastically reduced their agent's freedom once they hit production scale. Every action was gated behind validation. Every tool call was approved.
I didn't learn this lesson the easy way. Here's what our guardrail stack looks like at SIVARO:
python
class GuardrailValidator:
"""
Validates every tool call before execution.
Never trust the model. Always verify.
"""
def validate_tool_call(self, tool_call):
# 1. Schema validation
if not self.schema_parser.validate(tool_call.arguments):
return ValidationResult(reason="invalid_schema")
# 2. Permission check
if not self.auth_service.can_call(tool_call.tool_name, tool_call.user):
return ValidationResult(reason="insufficient_permissions")
# 3. Rate limit check
if not self.rate_limiter.allow(tool_call.tool_name):
return ValidationResult(reason="rate_limited")
# 4. Cost estimation check
estimated_cost = self.cost_model.estimate(tool_call)
if estimated_cost > self.max_allowable_cost:
return ValidationResult(reason="cost_exceeded")
# 5. Validation data check
if not self.semantic_validator.validate(tool_call):
return ValidationResult(reason="semantic_error")
return ValidationResult(approved=True)
The key insight? Each validation step catches a different class of error. The schema parser catches deterministic issues. The permission check catchesescape hatches. The rate limiter prevents cascading failures. The cost model prevents financial disasters. The semantic validator catches the errors that don't look like errors.
My contrarian take: most teams skip the semantic validator because it's hard to build. That's a mistake. The semantic validator is the only thing standing between your agent and a customer-facing hallucination.
The Retry Problem: When "Try Again" Makes Things Worse
Let's talk about the 2:47 AM incident.
The root cause was simple: a downstream API was down. The agent's error handler attempted a retry. The retry failed. So it retried again. Each retry consumed tokens. Each token generation created new context. The growing context confused the model. It started calling the wrong functions. Each function call wrapped in another "error recovery" attempt. The result was a feedback loop that burned $4,300 in API credits.
The fundamental problem: default retry logic designed for microservices doesn't apply to agents.
| Retry Strategy | Best For | Risk |
|---|---|---|
| Simple retry | Idempotent reads | Amplifies load |
| Exponential backoff | Rate-limited APIs | Still amplifies errors |
| Circuit breaker | Degrading services | Halts operation entirely |
| Graceful degradation | Partial failures | Requires fallback paths |
| Fallback to simpler model | Cost reduction | Reduces quality |
Exponential backoff didn't save us — it just slowed down the bleeding. The problem wasn't the retry frequency; it was that the agent interpreted the retry failure as "this task is hard" rather than "this service is down."
Here's what works better. Instead of letting the agent decide when to retry, you decide:
python
import asyncio
from tenacity import retry, stop_after_attempt, wait_exponential
@retry(
stop=stop_after_attempt(3),
wait=wait_exponential(multiplier=1, min=2, max=10),
reraise=True
)
async def call_agent_component(agent_function, *args, **kwargs):
"""
The ONLY retry logic you should trust.
External retry logic, not model-driven.
"""
try:
# Pattern to pass into the agent
result = await agent_function(*args, **kwargs)
# Check if the result is actually valid
if not validate_output(result):
# Don't retry the model, retry the *call*
raise ValueError(f"Invalid output: {result}")
return result
except RateLimitError as e:
# Specific handling for rate limits
raise e
except TimeoutError as e:
raise e
except HallucinationDetectedError as e:
# Don't retry — the context window is corrupt
raise e
The distinction between retrying the call and retrying the model is everything. If the model produced a hallucinated response, retrying the same prompt with the same context will just produce the same hallucination. Your retry logic needs to distinguish between failures that are transient (API timeouts) and failures that are inherent to the model's state (confused context, corrupted outputs).
This is one of the core ai agent error handling in production principles that most implementations get wrong. As the Blaxel team's guide on deploying AI agents to production notes: proper error handling needs to be deterministic, not model-driven. The model can't be trusted to decide when to retry, because the model is part of the system that's failing.
The Architecture of Control: Who's Really in Charge?
Here's the philosophical question that defines agent error handling: who owns the decision loop — the model or your code?
Most early agent frameworks gave the model ownership. The model determines next steps, decides when to call tools, decides when an action fails. This works in demos. In production, it's a disaster.
The approach we've converged on at SIVARO is what the Towards Data Science comparison of workflows vs agents calls a "controlled workflow" pattern. The model proposes. Your code disposes.
python
# Pattern: Controlled Workflow
# The ORCHESTRATOR decides — the MODEL proposes
class AgentOrchestrator:
def __init__(self):
self.state = AgentState.INITIAL
self.max_attempts = 3
self.require_human_approval = True
def run(self, task):
"""
Runs the agent with explicit control points.
Every critical decision is gated by the orchestrator.
"""
attempt = 0
while attempt < self.max_attempts:
try:
proposal = self.model.propose_next_step(self.state)
# Critical gate: validation before execution
if not self.validator.validate(proposal):
self.state = AgentState.BLOCKED
return Blocker(proposal)
# Critical gate: human approval for irreversible
# actions
if self.requires_approval(proposal):
user_approved = self.wait_for_human_approval(proposal)
if not user_approved:
return Cancelled()
result = self.execute(proposal)
self.state = AgentState.UPDATED(result)
attempt = 0 # reset on success
except ExternalAPIError as e:
attempt += 1
if attempt >= self.max_attempts:
return CircuitBroken()
time.sleep(2 ** attempt) # exponential backoff
except OutputValidationError:
# Don't retry — regenerate from clean state
return InvalidOutput(clear_context=True)
Why does this work? Because the orchestrator — not the model — makes all the important decisions. When an error occurs, the orchestrator's logic takes over. It doesn't ask the model to figure out what went wrong. The model is not allowed to debug itself. It's the same reason you don't ask the same doctor to re-diagnose a disease they already misdiagnosed — they'll likely repeat the same flawed reasoning with different wording.
Observability: You Can't Fix What You Can't See
Now we get to the word that makes your CTO salivate: observability.
The Machine Learning Mastery guide on deploying AI agents makes a point that I think most observability tooling vendors get wrong. They focus on tracing the sequence of API calls, which treats the model like a black box oracle. But the errors that matter are semantic. The chain of actions was structurally correct. The model's reasoning was internally consistent. The output — was wrong.
That means your ai agent observability tools for production need to do more than track latency and token counts. They need to track intent.
python
# Observability: Beyond token counts
def log_agent_interaction(agent_id, user_query, tool_calls, final_response, metrics):
"""
Log every decision the agent makes.
Not just what happened, but WHY.
This is your post-mortem toolkit.
"""
structured_log = {
"agent_id": agent_id,
"user_query": user_query,
"tool_calls": [
{
"tool": tc.tool_name,
"arguments_schema_valid": tc.args_valid,
"permission_check_passed": tc.permission_passed,
"cost_exceeded": tc.cost_exceeded,
"output_valid": tc.output_valid,
"exec_time_ms": tc.exec_time_ms,
"error_type": tc.error_type,
"error_message": tc.error_message,
}
for tc in tool_calls
],
"final_response": final_response,
"timing": {
"total_time_ms": metrics.total_time_ms,
"model_latency_ms": metrics.model_latency_ms,
"tool_latency_ms": metrics.tool_latency_ms,
},
"context": {
"context_window_size": metrics.context_size,
"truncation_occurred": metrics.truncated,
"tokens_used": metrics.tokens_used,
},
}
# Write to your observability platform
# (OpenTelemetry, Langfuse, Datadog, whatever you use)
trace.write(structured_log)
If your observability stack doesn't include why the agent made the error, you're not doing observability — you're doing logging. The difference matters when debugging production incidents.
Here's a rule of thumb I've developed: you need three types of traces.
Call traces — What happened in order. Each tool call, each response, each state transition. These are cheap and easy.
Decision traces — Why the agent chose what it chose. What alternatives were considered. What the confidence scores were. Models can provide this — the keys are whether the tokens passed through the decision gate are logged.
Validation traces — What your guardrails caught. Every blocked call. Every rejected tool. These are the most valuable logs you'll ever produce. They show exactly where your error handling is preventing problems vs. where the model is fighting your rules.
At SIVARO, we've standardized on OpenTelemetry for the tracing backbone. But I'll be honest: the tool doesn't matter nearly as much as the discipline. Log the bad stuff. Log the near-misses. Log the decisions, not just the actions.
The Five Failure Modes of Production Agents
Let me walk you through the failure modes that will actually hit you, in order of frequency. Based on watching production agents fail for several years now.
The Infinite Loop
Your agent is stuck trying to complete a task, failing midway, retrying, failing again. It looks like it's "working" because it keeps calling tools. It's not. It's a hamster wheel.
The fix? Set a hard iteration limit before deployment. Kill the agent if it exceeds that limit. Do not let the model determine when to quit — models absolutely don't balance the cost of iteration.
The Hallucinated Success
The agent reports the task is complete. It's not. The output is fabricated. This is the most dangerous because it doesn't look like an error. No exception was raised. No validation failed. The model just decided the output was good enough.
The fix? Semantic validation. The validator needs to check the process, not just the output. Was the search actually run with real parameters? Did any tool return a "not found" that got ignored?
The Confident Wrong Answer
This is different from hallucinated success. The agent confidently provides the wrong information. It might be slightly wrong — a bad date, an incorrect summary. Or it might be completely wrong — a fabricated citation or a made-up quote.
The fix? This is where evaluation frameworks — like adding context-window constraint checkers to the prompt — come in. You must test against a golden dataset of expected outputs and measure semantic proximity, not just exact matches.
The Cascade
A single error at the beginning results in a chain of corrupted outputs. If the first tool call resturns bad data, every subsequent action is built on that bad foundation.
The fix? Context gating. Before each major step, validate that any external data used in the last step was verified. If something failed earlier, do not let the agent proceed with the corrupted data.
The Over-Engineering Trap
Your agent was given too much autonomy. It decided to write its own helper functions, take shortcuts, skip steps. The output looks fine but the process was chaotic. In production, this increases both costs and failure risk.
The fix? Tighter workflow constraints. As Anthropic pointed out, some of the most successful production agents at companies like Klarna rely on carefully planned deterministic workflows — not open-ended autonomy.
Budgeting for Failure: The Financial Reality
The 2:47 AM incident cost us $4,300. The only reason it wasn't $43,000 was that I spotted it at $4,300 and killed the process.
Here's what I now do for every agent at SIVARO: set a hard budget limit before deployment.
python
# Cost Control: Not optional
class AgentBudget:
def __init__(self):
self.monthly_limit_usd = 5000
self.cost_map = {
"gpt-4o": 0.0025, # per input token
"gpt-4o": 0.010, # per output token
"claude-sonnet-4": 0.003,
"claude-sonnet-4": 0.015,
}
self.spent_this_month = 0
def should_block_request(self, model, input_tokens, output_tokens):
estimated_cost = input_tokens * self.cost_map[model][0]
+ output_tokens * self.cost_map[model][1]
projected_total = self.spent_this_month + estimated_cost
# Block if projected spend exceeds monthly limit
if projected_total > self.monthly_limit_usd:
return True, "monthly_budget_exceeded"
# Also block if projected spend is above a *daily* limit
daily_limit = self.monthly_limit_usd / 30
if self.spent_today + estimated_cost > daily_limit * 2:
return True, "daily_budget_exceeded"
return False, None
Anyone who tells you cost is not a reliability issue doesn't understand production. An out-of-control agent doesn't just cost money — it cascades into other systems. It locks up APIs. It exhausts rate limits. It generates alerts that desensitize your on-call team.
The Concurrency Trap
Here's the architecture problem nobody talks about enough.
Your development environment has one user. One agent. One conversation. Your production environment has 500 users, 500 agents, 800 concurrent conversations. That changes the error profile entirely.
When you have one agent and it fails, you can debug it. When you have 500 agents and they all start failing at once — maybe because an upstream API degraded — you'd better have a circuit breaker at the orchestrator level, not just within a single agent's execution.
python
class AgentService:
"""
Global circuit breaker for all agent instances.
"""
def __init__(self):
self.circuit_states = {} # key: service_name
self.request_counts = {} # key: service_name
self.failure_counts = {}
self.CIRCUIT_BREAK_THRESHOLD = 10
def check_circuit(self, service_name):
if self.failure_counts.get(service_name, 0) > self.CIRCUIT_BREAK_THRESHOLD:
return "OPEN" # Requests are blocked
elif self.failure_counts.get(service_name, 0) > self.CIRCUIT_BREAK_THRESHOLD * 0.7:
return "HALF_OPEN" # Some requests allowed
else:
return "CLOSED" # Fully operational
def record_failure(self, service_name):
self.failure_counts[service_name] = self.failure_counts.get(service_name, 0) + 1
def record_success(self, service_name):
self.failure_counts[service_name] = 0
If you don't implement this, you will spend a weekend where every agent in your system fires at an unhealthy API simultaneously, consuming hundreds of thousands of tokens, and no single agent is responsible. It's a systemic failure, which requires a systemic fix.
The Evaluation Pipeline: Your Second Chance
I mentioned evaluation earlier —- the hardest part of ai agent error handling in production is that you can't easily test errors.
Here's the workflow that saved us more than any other investment:
Create a curated set of "error scenarios" that mirror what production throws at you: API timeouts, malformed responses, empty result sets, conflicting data. Force your agent to handle each one in staging. Watch what it does.
Build a golden-set evaluation harness that runs your agent across the curated scenarios after every prompt change, after every model update. This catches 80% of the errors early.
python
# Evaluation harness example
def run_evaluation_suite(agent, scenarios):
results = []
for scenario in scenarios:
try:
result = agent.run(scenario.input)
pass_fail = assess_result(result, scenario.expected)
results.append({
"scenario": scenario.name,
"pass": pass_fail,
"error": None,
"result": result
})
except Exception as e:
results.append({
"scenario": scenario.name,
"pass": False,
"error": str(e),
"result": None
})
# Compute pass rate
# Block deployment if pass rate < 90%
return results
If your error-rate is above 10%, you aren't ready for production.
When Humans Need to Step In
Here's the thing nobody brags about at conferences: some errors require human judgment. Not because the model can't handle it — but because the stakes are too high to trust the model.
The line, for us, is drawn at: irreversible actions.
If the agent is making an API call that can't be undone, if it's closing a ticket, if it's deleting a row, if it's spending money beyond a threshold — a human needs to approve it.
Does this reduce autonomy? Yes.
Does it reduce errors? Dramatically.
The right question isn't "can the agent handle this?" It's "what happens when it fails?" If the answer to that second question contains any of these words — irreversible, permanent, expensive, legal, embarrassing — the agent doesn't get unconstrained access.
The Tools That Actually Help (And the Ones That Don't)
The ones that help:
- Langfuse or Langsmith for tracing agent decision flows and wire traces from ai agent observability tools for production
- OpenTelemetry for standardizing the transport layer of your traces
- A simple LLM-based "opponent" that evaluates your agent's outputs as an adversarial filter
- An in-app umbrella interface that your engineers can build to review an agent's actions after incidents
The ones that don't:
- Logging libraries that only show you the raw model outputs. You'll have gigabytes of logs and no idea what events led to your incident.
- Monitoring dashboards that focus on latency only. Your token costs are a valid metric; your decision quality is a better one.
- A custom telemetry stack that your team built and nobody will maintain.
The Recovery Playbook
Alright, the worst has happened. Your agent is live in production, it's failing, and you need to recover. Here's what to do first, in order:
1. Kill it. In the first 60 seconds, your only job is to stop the bleeding. That means either shutting down the agent service, or — more effectively — shutting off its network access.
2. Isolate. Make sure no other agents are impacted. If they are, shut those down too. Do not let a systemic failure cascade.
3. Find the root cause. Now you can debug. Go through your observability logs (the decision traces I mentioned above) and reconstruct the chain of events.
4. Fix. Test. Redeploy. Update the agent's validation rules, add a guardrail, or change the retry logic. Run it against your evaluation suite. Deploy.
5. Write the post-mortem. This is the part most people skip, but it's the most important. Write down what happened, why it happened, and what you'll change to prevent it. This post-mortem will be your guide for the next agent you build.
Looking Forward: The State of the Industry
We're in a weird place right now in the agent ecosystem. Every vendor claims production readiness. Most aren't there. Google's research paper was surprisingly candid about the gaps between hype and reality. I appreciate the honesty.
The biggest shift I've seen is the move toward AI agent error handling in production becoming a discipline into its own right, rather than a side note to agent development. Companies are starting to build "reliability engineering" teams specifically for agents. They're writing books about incident response for AI systems. Conferences are devoting whole tracks to this.
The good news is that the playbook exists. The bad news is that most teams are still following the early-playbook-agile approach: deploy, wait for the 2:47 AM call, then fix it.
I'm hoping this guide helps you skip that call.
FAQ: Agent Error Handling in Production
Q: How many retries should an agent attempt before giving up?
A: Three, maximum. If it hasn't succeeded in three attempts, the agent is likely part of the problem. Any more retries just amplifies the failure.
Q: What's the best way to handle hallucinations in production?
A: Prevent them, not detect them. Use deterministic workflows where possible, strict schema validation on tool outputs, and semantic validity checks. If you detect them, drop the entire context and start over rather than trying to "fix" the conversation.
Q: Should the agent handle its own errors or should external code handle them?
A: External code, always. The agent can't be both the system and the observer. If the model's context is corrupted, it will make bad error-handling decisions. Your orchestrator should be the only thing deciding when to retry, when to fail, and when to escalate.
Q: What architecture is better for error-prone environments: agent or workflow?
A: Workflow, by a mile. If your task is highly structured, use a deterministic workflow with an LLM handling the "flexible" parts. Pure agents work in sandboxes. Real systems need guardrails.
Q: How do I test for errors I haven't seen yet?
A: You can't predict everything. But you can simulate common failure modes — API timeouts, rate limits, malformed responses, empty results. Build a library of adversarial scenarios and run your agent against them after every change. Use your production logs systemically to improve your hypotheses.
Q: What's the cheapest way to start doing error handling well?
A: Start with schema validation on every tool input and output. That catches the most errors for the least amount of engineering. Then add retry logic with exponential backoff. Then add circuit breakers. Then invest in the semantic validation.
Q: How do I convince my team to spend time on error handling instead of building more features?
A: Show them the 2:47 AM call. Wait for it to happen. Then show them the post-mortem, the cost analysis, and the time lost. One production incident will do more for your reliability budget than a hundred architectural debates.
Q: Is there a way to handle errors without spending extra tokens on retries?
A: Not perfectly. But you can reduce the token cost by separating validation logic from main-agent reasoning. Use a cheaper model to check the main model's output. Use deterministic logic on tool outputs. Token costs are part of the reliability equation.
Q: What data should I be logging for post-incident analysis?
A: For every decision point, log: the tool call, the reason the agent chose it, the confidence level, the validation result, and the time taken. Log the low-level metrics too, but the decisions are what tell you what went wrong.
Final Thought
The truth about error handling is that it's an ongoing practice, not a fixed feature. You will always be learning from production incidents — the goal is to have each of them be more educational and less catastrophic.
At SIVARO, we built an entire system around handling production errors. But I'll say it openly — we didn't get everything right. We got it right enough to survive our own production incidents and build agents that operate reliably under real-world conditions.
The architecture I've described in this guide is the one I wish I had when I started. The tools, the validation, the budgets, the circuit breakers, the evaluation harnesses.
Build your agents with the capability of success. But build them for a world where failure is normal, errors are inevitable, and your role is to make the failure graceful, contained, and correctable.
Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.