What should happen when an AI agent fails in production?

What matters first

When an AI agent fails in production, the system should:

stop unsafe or unclear actions,
classify the failure,
preserve the evidence,
route the case to the right human or fallback path,
and decide whether the issue is local, systemic, or rollout-related.

The worst production pattern is silent failure followed by hidden manual rescue.

The wrong failure plan

The weak plan is:

“Retry until it works.”

That only helps when the failure was:

transient,
low-risk,
and tied to an idempotent action.

If the run failed because of missing evidence, wrong authority, weak approval logic, or a dangerous side effect, blind retries make the incident worse.

The first decision: is this a safe-stop failure?

Some failures should stop immediately:

policy or permission violations,
missing required evidence,
high-consequence ambiguity,
tool actions that are not safely repeatable,
or any run that may have crossed the wrong authority boundary.

These are not retry cases. They are containment cases.

The second decision: is this retryable?

Retries are justified only when:

the failure is transient,
the step is idempotent,
the system knows what changed,
and retrying does not widen the blast radius.

Examples include flaky upstream services or temporary tool timeouts. Even then, retries should be bounded and logged.

The third decision: who owns the handoff?

A failed run should not disappear into generic “manual review.”

The system should hand off:

what the task was,
what evidence it used,
which tools were called,
what failed,
and what the likely next action is.

This prevents the human rescue path from turning into full rediscovery.

What the system should record every time

Every meaningful failure should capture:

a stable run ID,
workflow class,
failure class,
retry count,
approval state,
tool and model context,
final handoff target,
and whether the issue implies rollback or narrower permissions.

Without this, teams remember dramatic failures and forget the expensive repeated ones.

When failure should trigger rollback

Rollback should be considered when:

a new version created a clear regression,
high-severity failures increased,
approval boundaries drifted,
or operator rescue work spiked after a release.

Not every bad run is a rollback event. But every rollback event starts as a set of badly understood failures.

The practical production rule

For each failure class, decide in advance:

stop or retry,
who gets the handoff,
what evidence must be preserved,
what metric would trigger rollback or tighter scope.

That turns failure handling from improvisation into operations.

Implementation checklist

Your production failure plan is probably healthy when:

unsafe cases fail closed instead of retrying blindly;
retryable cases are narrow and idempotent;
handoff packets preserve context instead of discarding it;
logs can distinguish one-off failure from rollout regression;
and owners know which failure patterns trigger rollback, approval tightening, or evaluation updates.

Compare next

What should you log for an AI agent in production? Use this page when the failure plan is weak because the logs still cannot explain what happened.

When should an AI agent escalate to a human? Use this page when the failure boundary is really an escalation rule problem.

How do you roll back an AI agent in production? Use this page when failures now raise release, rollback, and version-ownership questions.

Tool timeouts, retries, and idempotency Use this page when the real failure question is which runs deserve retries at all.

Reader value check

This page should help a reader decide where responsibility, approval, escalation, and handoff should sit in the operating flow. For What should happen when an AI agent fails in production?, the page is not finished if it only explains vocabulary. It should change what the team approves, measures, routes, buys, logs, or refuses to automate.

Before applying the guidance, bring real tickets, runbooks, escalation examples, review delays, and failure cases from the workflow. Those inputs keep the decision anchored in real operating conditions instead of a generic best-practice list.

Check	What the reader should be able to answer
Trigger	Is the event that starts the workflow explicit enough for a team to recognize it?
Owner	Does each step have a human or system owner instead of a vague shared responsibility?
Stop rule	Does the page say when the workflow should pause, escalate, or roll back?
Evidence	Can a reviewer reconstruct what happened from logs, traces, tickets, or approvals?

Use the page as a working review artifact: compare the current workflow against the table, mark the missing evidence, and assign an owner for the next change. If the page exposes a gap but no one owns that gap, the correct next step is not broader rollout; it is a smaller pilot, a clearer gate, or a better measurement loop.

For workflow pages, the value is operational clarity. The page should help a team remove ambiguity before the agent acts, not after an incident has already exposed the gap.