AI Agent Error Recovery: A Product Manager's Guide

Why Agent Errors Are Different From API Errors

When a REST API returns a 500, the failure is local and visible. Your error handling catches it, retries or surfaces a message, and the rest of your system is unaffected. Agent errors do not work this way.

An AI agent is a reasoning loop: plan a step, call a tool, observe the result, decide what to do next. When something goes wrong at step two of a ten-step workflow, the agent often does not stop. It reasons about the result it got, decides how to continue, and proceeds. By step seven, the downstream consequences of that early error have compounded into a state that is hard to diagnose and sometimes impossible to reverse.

The compounding error problem: an example

Step 1Agent reads a customer record to draft a renewal email.

Step 2Tool call fails silently; agent receives an empty response.

Step 3Agent reasons that the customer has no active contracts and drafts a win-back email instead.

Step 4Agent calls send-email tool with incorrect framing.

Step 5Active customer receives a win-back offer implying they churned.

The root failure was a silent tool error at step two. The user-visible damage was a trust incident at step five. Traditional error handling would have caught step two. Agent error recovery requires you to anticipate compounding and build recovery into the design, not just the exception handler.

The Agent Error Taxonomy: Five Types PMs Need to Define

Before you can design recovery, you need to name what can go wrong. Most agentic failures fall into five categories, each with a different root cause and a different recovery approach.

Tool call failure

Cause: An external API returned an error, timed out, or returned malformed data. The agent may not correctly interpret the failure.

Signal: Tool response contains an error code, an exception, or an unexpectedly empty payload.

Risk: Medium to high. Depends on whether the agent correctly identifies it as a failure and whether it continues.

Hallucinated tool argument

Cause: The agent invokes a real tool with a fabricated or incorrect argument (wrong customer ID, nonexistent file path, stale API key).

Signal: Tool call succeeds structurally but operates on the wrong target. Often indistinguishable from a success without post-call validation.

Risk: High. The agent proceeds confidently on a false premise. No error is raised.

Context overflow or truncation

Cause: The accumulated context (prior steps, tool outputs, intermediate reasoning) exceeds the model's context window. Earlier context is silently dropped.

Signal: Agent loses track of earlier constraints, repeats completed steps, or contradicts earlier decisions.

Risk: High for long workflows. Unpredictable: the model does not signal that it lost context.

Permission or scope error

Cause: The agent attempts an action it is not authorized to take (write to a restricted folder, send on behalf of a user, access a protected record).

Signal: Permission denied error from the tool layer. Well-defined if your tool schemas include scope constraints.

Risk: High for trust and compliance. Low for compounding if the error is surfaced immediately.

Reasoning drift

Cause: The agent correctly completes each individual step but gradually drifts from the original goal due to accumulated small deviations in interpretation.

Signal: Hard to detect without goal-state validation at end of workflow. The output may be technically correct but misses the user's actual intent.

Risk: High for user trust. Common in long-running autonomous agents.

Recovery Patterns: Which to Apply and When

Each error type maps to one or more recovery patterns. Your design spec should explicitly state which pattern applies to each error in your agent's taxonomy. Leaving it to the model to decide at runtime is how silent failures become user trust incidents.

Retry with backoff

When: Tool call failure due to transient error (rate limit, timeout, 503). Use for idempotent operations only.

Limit: Set a max retry count (typically 3) and surface a failure message if exceeded. Never retry a non-idempotent operation without user confirmation.

Fallback to simpler path

When: A tool or capability is unavailable and a degraded version of the task is better than a full stop.

Limit: Define what 'simpler path' means explicitly. An agent left to define its own fallback will choose something the PM did not intend.

Checkpoint and pause

When: A long-running workflow hits an ambiguity that requires human input. Common in workflows that touch external systems or make irreversible changes.

Limit: Design the pause state carefully. Users who return to a paused agent need to understand exactly what happened and what decision is needed.

Hard stop with explanation

When: Permission error, hallucinated argument detected by post-call validation, or reasoning drift detected by goal-state check.

Limit: The explanation must name the specific step that failed, not just 'an error occurred.' Vague stops destroy trust faster than transparent failures.

Human handoff

When: The agent cannot recover on its own and the task is too important to abandon. Common in customer support and compliance workflows.

Limit: Pass full context to the human agent, including what the AI attempted, what failed, and what state the workflow is in. A handoff without context is a transfer to nowhere.

Rollback to last good state

When: The agent made changes (wrote data, sent messages, updated records) based on a step that later proved incorrect.

Limit: Rollback is only possible if you checkpoint state before each destructive action. Design for rollback from the start; retrofitting it is expensive.

Ship Agentic Products With Confidence

The AI PM Masterclass covers agentic product design, reliability frameworks, and how to spec AI features that your engineering team can actually build and test. Taught live by a Salesforce Sr. Director PM.

Designing Error-Resilient Agent UX

The way you surface errors is as important as the recovery logic behind them. Agent failures that are visible but explained maintain user trust. Agent failures that are silent or cryptic destroy it.

Name the failed step, not the system

Say 'I could not retrieve the contract for Acme Corp. Want me to try again or search manually?' not 'An error occurred.' Users who know what failed can help. Users who see 'error occurred' close the tab.

Show progress before failure

If your agent completed four steps before hitting an error, show those four steps. Users who see partial progress trust the system more than users who see a blank response with an error message.

Offer a specific next action, not a vague apology

Every error state should have a primary action: retry, take a different approach, or hand off to a human. An error state with no action is a dead end. Most users will not know to rephrase their request.

Distinguish reversible from irreversible errors

A failed email send (the action did not happen) requires different UX than a sent-duplicate-email error (the action happened twice). Users need to know whether recovery requires action on their part.

Use escalating transparency

Show minimal error detail by default. Give users a way to expand to full technical context. Most users want 'it failed, here is what to do.' A subset of users want the full stack trace. Design for both.

Testing and Measuring Agent Reliability

You cannot rely on happy-path testing for agentic products. Standard QA runs the intended workflow; agent reliability testing runs the edge cases your users will eventually find. Here is how to structure both the test strategy and the metrics.

Pre-launch testing checklist for agentic features

Define a failure scenario for each error type in your taxonomy before writing test cases.

Test tool failure injection: force each tool to return errors, empty responses, and malformed data.

Test context overflow: run your longest realistic workflow and verify the agent does not lose earlier constraints.

Test permission boundary: attempt every action your agent can take with insufficient permissions.

Test goal drift: run multi-step workflows with ambiguous instructions and validate the final output against the original intent.

Test rollback: confirm your state checkpointing actually recovers to the correct prior state, not an approximation.

After launch, track these four metrics. They are the minimum viable reliability dashboard for an agentic product.

Task completion rate

Percentage of initiated workflows that reach the intended end state without user intervention.

Benchmark against your design spec. For high-stakes workflows, aim for 95%+. For exploratory workflows, 80% may be acceptable.

Recovery rate by error type

For each error type in your taxonomy, what percentage of occurrences result in successful recovery versus hard stop or user abandonment?

Low recovery rate on a specific error type points to a specific recovery pattern that needs work.

Mean time to escalation

For errors that require human handoff, how long between error occurrence and user receiving human support?

Depends on use case. For support workflows, under 5 minutes is generally acceptable.

Silent failure rate

Percentage of agent runs that completed without error but produced a result that users subsequently rejected or flagged.

Requires user signal (thumbs down, undo, complaint). Hard to measure but highest-risk failure mode.