Agent Error Recovery & Resilience: When Your Agent Fails Gracefully — Or Catastrophically

Error Recovery Failure Taxonomy

1. The "Give Up Immediately" Problem

Agent encounters an error: API returns 500. Agent: "I encountered an error and cannot complete this task." No retry, no fallback, no degradation. The error was transient — a retry 2 seconds later would have succeeded. The agent's zero-resilience policy turned a 2-second delay into a complete task failure. Measure: retry behavior — does the agent retry on transient errors? With what backoff strategy?

2. The "Retry Until Doomsday" Problem

Agent retries — but with no limit. API returns 429 (rate limited). Agent retries immediately — still 429. Retries again — 429. Retries 47 times in 30 seconds — all 429s. The agent consumed its entire rate limit budget on retries, exhausted its context window on retry attempts, and produced no output. Opposite of give-up: the agent that can't recognize when retrying is futile. Measure: retry limit and backoff intelligence.

3. The "Silent Degradation" Problem

Agent encounters an error in a sub-step: "research competitor 7's pricing" fails because the competitor's pricing page is behind a login wall. Agent silently skips competitor 7 and continues. Final output: "Analysis of 10 competitors" — but it only analyzed 9. The degradation is invisible — the user doesn't know data is missing. Measure: degradation transparency — does the agent report what it couldn't do?

4. The "Partial Output" Problem

Agent completes 70% of the task, then hits a fatal error. Three possible behaviors: (a) return nothing — "I failed" (all work lost), (b) return the 70% with a note — "I completed 7 of 10 competitor analyses. Competitors 8-10 failed because [reason]. Here's what I have so far" (useful partial output), (c) return the 70% silently — no mention that 30% is missing (dangerous partial output). Measure: partial output quality — completeness, transparency, usefulness.

5. The "Error Cascade" Problem

Step 1 fails → step 2, which depends on step 1's output, receives garbage → step 2 produces garbage → step 3, which depends on step 2, produces worse garbage. The error compounds through the pipeline. The final output is 100% wrong but the agent presents it confidently. Measure: error propagation detection — does the agent recognize when upstream errors invalidate downstream results?

The Resilience vs Cost Tradeoff

Resilience costs tokens: retries consume LLM calls, fallback approaches consume tool calls, detailed error communication consumes output tokens. An agent with max resilience might spend 3× the tokens of a fragile agent on the same task. The tradeoff:

• Critical tasks (financial analysis, customer-facing output): high resilience is worth the cost
• Exploratory tasks (initial research, draft creation): lower resilience is acceptable — the user will iterate anyway

The agent that adapts resilience to task criticality is efficient. The agent that applies max resilience to everything wastes tokens. Measure: resilience appropriateness — does the agent match resilience level to task criticality?