Error Handling and Recovery Policies for LLM Agents
You built an agent. It works great in the demo. Then you put it in production, and it starts hallucinating file paths, calling APIs with broken JSON, or getting stuck in a loop trying to fix a mistake it made three steps ago. This isn't a bug; it's the nature of Large Language Model (LLM) agents. Unlike traditional software where code is deterministic, LLMs are probabilistic. They guess. And sometimes, they guess wrong.
The difference between a toy project and a reliable system isn't just the model size-it's how you handle failure. If your agent crashes when one tool call fails, it's fragile. If it detects the error, rolls back, tries a different approach, or asks for help, it's robust. This article breaks down the specific strategies for catching errors and recovering gracefully in modern agentic systems, moving beyond simple "try-catch" blocks to structured, phase-aware recovery policies.
Why Traditional Error Handling Fails Agents
In standard programming, an error usually means something broke: a null pointer, a missing file, a syntax error. The stack trace tells you exactly what happened. In LLM agents, failures are often silent or semantic. The code runs fine, but the output is logically wrong. The agent might return valid JSON that contains a non-existent user ID, or it might plan a sequence of steps that makes no sense in the real world.
This nondeterminism creates unique challenges:
- Hallucination Propagation: A small factual error in step 1 can compound into a catastrophic failure by step 10.
- State Drift: The agent thinks it wrote a file, but the external system didn't actually save it. Now the agent's internal state disagrees with reality.
- Nondeterministic Outputs: Running the same prompt twice might yield different results, making debugging a nightmare if you don't log everything.
You cannot rely on exceptions alone. You need a policy that validates intent, checks state, and has multiple layers of fallback.
The SHIELDA Framework: Phase-Aware Exception Handling
Recent research, specifically the SHIELDA framework (Structured HandlIng of Exceptions in LLM-Driven Agentic Workflows), highlights that not all errors are created equal. They occur at different phases of the agent's life cycle, and each phase requires a different recovery strategy.
Think of an agent's operation in three distinct stages:
- Reasoning Phase: The agent thinks about what to do. Errors here include ambiguous goals or logical contradictions in the plan.
- Planning Phase: The agent structures the workflow. Errors here involve invalid dependencies or impossible sequences.
- Execution Phase: The agent acts. Errors here are technical: API timeouts, malformed JSON, or permission denials.
A generic retry button doesn't work well across these phases. If the reasoning is flawed, retrying the execution won't help. You need to go back and re-plan. SHIELDA suggests using an exception classifier to identify which phase failed, then selecting a specific handling pattern from a registry. This modular approach prevents the "brute force retry" anti-pattern, where an agent wastes tokens trying to execute a fundamentally broken plan.
Core Recovery Strategies: From Simple to Complex
When an error occurs, you shouldn't jump straight to calling a human. That's expensive and slow. Instead, implement a hierarchy of recovery mechanisms, starting with the cheapest and most automated options.
1. Schema Validation and Sanitation
The first line of defense is strict validation. Before your agent uses any LLM output, check it against a predefined schema. Tools like Pydantic are excellent for this. If the LLM returns a string instead of an integer, or misses a required field, catch the ValidationError.
Don't just fail. Route the bad output to a "sanitizer." This could be a smaller, cheaper model tasked solely with fixing formatting, or a rule-based script that coerces types. Only if sanitation fails should you trigger a regeneration. This saves costs and latency by avoiding full re-generation for minor syntax issues.
2. Multi-Template Prompt Fallback
Sometimes, the issue isn't the data, but the instruction. If a prompt consistently produces vague answers, don't just retry the same prompt. Switch to a backup template. Keep multiple versions of critical prompts in your system:
- Template A: Direct and concise.
- Template B: Detailed with examples (few-shot).
- Template C: Step-by-step chain-of-thought.
If Template A fails semantic validation, automatically invoke Template B. This treats prompt variation as a first-order recovery mechanism. It’s surprisingly effective for handling nondeterministic behaviors without changing the underlying model.
3. Checkpointing and Plan Rewinding
For multi-step workflows, restarting from scratch is wasteful. Implement checkpointing. After every successful step, save the state. If step 5 fails, rewind to the checkpoint after step 4. Store side effects in reversible formats-like git stashes for code changes or temporary files for data writes-so you can undo partial progress cleanly.
| Strategy | Best For | Cost | Complexity |
|---|---|---|---|
| Schema Sanitation | Formatting errors, type mismatches | Low | Low |
| Prompt Fallback | Vague outputs, instruction following | Medium | Medium |
| Plan Rewinding | Multi-step workflow failures | High | High |
| Human-in-the-Loop | Ambiguous goals, high-stakes actions | Very High | Low (Tech) |
Handling State Verification and Silent Failures
The scariest errors are the ones you don't see. An agent calls an API, gets a 200 OK response, and assumes success. But maybe the database update didn't commit, or the file wasn't written due to permissions. This is a silent failure.
To combat this, implement post-execution verification. Don't trust the action; verify the result. After writing a config file, query the filesystem to confirm it exists. After updating a record, fetch it again to check the values. If the expected state doesn't match the actual state, trigger a rollback or re-plan. This "trust but verify" approach is critical for agents interacting with external systems like databases, cloud infrastructure, or third-party APIs.
Memory Management and Corruption Recovery
Agents with long-term memory face a unique problem: contamination. If an agent stores a hallucinated fact in its memory store, it will retrieve that false fact in future interactions, leading to persistent errors. This is memory-level corruption.
Recovery strategies here differ from execution errors:
- Anomalous Entry Filtering: Use trigger-aware filtering to detect entries that contradict current context or established facts.
- Temporal Anchoring: Tag memory summaries with timestamps. This helps distinguish between outdated information and current truth, preventing the resurrection of contradicted facts.
- Segregation: Separate short-term working memory from long-term knowledge. If working memory gets noisy, clear it without wiping the core knowledge base.
Forgetting is a feature, not a bug. Implement decay mechanisms for low-utility memories so your agent doesn't drown in irrelevant noise.
The Role of Human-in-the-Loop Escalation
No matter how good your automated recovery is, some failures require human judgment. Ambiguous user intent, novel edge cases, or destructive operations (like deleting a production database) should trigger escalation.
Design your UI to present the agent's proposed action, the reason for uncertainty, and a clear "Approve," "Edit," or "Cancel" option. Capture these human corrections. Over time, use this feedback to refine your prompts and fallback logic. This creates a continuous improvement loop where the system learns from its mistakes, reducing the frequency of escalations over time.
Practical Implementation Checklist
Ready to harden your agent? Start with these concrete steps:
- Instrument Everything: Log retry counts, fallback paths taken, and error reasons. You can't improve what you can't measure.
- Define Schemas First: Use Pydantic or similar tools to enforce strict output structures before execution.
- Implement Backoff Strategies: Use exponential backoff for transient API errors, but cap retries to prevent infinite loops.
- Isolate Tool Wrappers: Wrap external tool calls in try-catch blocks that isolate failures, preventing one bad tool from crashing the whole agent.
- Test Failure Modes: Intentionally inject errors (e.g., mock API timeouts) during testing to ensure your recovery policies actually work.
Error handling isn't an afterthought. It's the architecture that keeps your agent alive when the real world refuses to cooperate. By combining phase-aware classification, layered recovery strategies, and rigorous state verification, you transform a brittle prototype into a resilient system.
What is the most common error in LLM agents?
The most common error is typically schema violation or malformed output. LLMs often generate text that looks correct but fails to parse as JSON, misses required fields, or uses incorrect data types. Strict schema validation using tools like Pydantic is the primary defense against this.
How does SHIELDA improve error handling?
SHIELDA improves error handling by categorizing exceptions based on the agent's operational phase (reasoning, planning, execution). Instead of a generic retry, it selects specific recovery patterns tailored to the phase where the failure occurred, allowing for more precise and efficient recovery, such as re-planning rather than just re-executing.
Should I always retry failed LLM calls?
No. Blindly retrying identical prompts is inefficient. If the failure is due to ambiguous instructions, retrying the same prompt will likely yield the same bad result. Use multi-template fallbacks or escalate to human review if the error is semantic or logical rather than transient.
What is state drift in agents?
State drift occurs when the agent's internal belief about the world differs from the actual state of external systems. For example, the agent thinks it saved a file, but the write failed silently. Post-execution verification queries are used to detect and recover from state drift.
How do I handle ambiguous user intent?
Handle ambiguous intent through proactive clarification. The agent should ask targeted questions to narrow down the goal, decompose high-level goals into subgoals, or propose the most likely interpretation for user confirmation before executing potentially destructive actions.
