What an AI agent should do when it fails

Failure is the design surface

Most agent design covers the successful path in detail and treats failure as an exception to be handled later. In production the ratio inverts: the happy path is straightforward, and almost all the engineering that matters is about what happens when something does not work.

The reason is structural. A person hitting an obstacle stops, thinks, and asks someone. An agent does whatever its failure handling says — and if that has not been specified, the default behaviour is usually to try again, immediately, with no limit.

Five failure classes, five responses

They are genuinely different and need different handling.

The costly mistake is treating all five as transient. Retrying a permanent failure wastes time and obscures the real cause. Retrying an ambiguous one is worse — the agent eventually picks arbitrarily, and the arbitrary choice is now recorded as a decision.

Retry limits are the most under-specified thing in agent design

Unbounded retries are how a small fault becomes an incident. A rate limit that would have resolved in ninety seconds turns into thousands of requests, a genuine outage, and a very confusing log.

Sane defaults:

• A hard attempt cap, typically two or three. Not "until success".
• Exponential backoff with jitter. Fixed intervals from many workers synchronise and produce thundering herds.
• A total time budget as well as an attempt cap. Three attempts spread over an hour is usually the wrong shape for a workflow expected to finish in minutes.
• Retry only the failed step, not the whole run, where the work is idempotent.
• A defined terminal state. When retries are exhausted, something specific must happen: escalate, mark failed, roll back. "Give up quietly" is not a state.

Partial completion is the hard problem

Multi-step workflows fail in the middle. The agent has updated two systems of three, and the third is unavailable.

There are only three honest strategies:

Compensate. Undo the completed steps with explicit reversing actions. This requires every step to have a defined inverse, which is real design work and is the reason it is rarely done properly.

Roll forward. Keep the completed work, mark the run incomplete, and escalate the remainder to a human with precise state. Usually the most practical option.

Leave and alarm. Stop, change nothing further, and raise loudly. Correct when the state is too complex to reason about automatically.

What is not acceptable is silent partial completion. If a run ends with the world half-changed and nothing records that fact, the next person to look will find an inconsistency with no explanation, possibly weeks later.

The design implication is worth stating plainly: order the steps so the irreversible ones come last. If a workflow updates an internal record and then emails a customer, do the reversible internal work first. Failing before the email is recoverable; failing after it is not.

Escalation only works if it is specific

"Escalate to the team" is not escalation. A useful escalation carries:

1. What was being attempted, in business terms.
2. What failed, and which class it falls into.
3. The state right now — which steps completed, which did not.
4. What the agent has already tried, including retries.
5. What it needs — a decision, a permission, a data fix.
6. What happens if nobody responds, and by when.

And it must go to a named person or a defined on-call role, decided before deployment. Escalation paths agreed during an incident are agreed badly.

The failure record is not an error log

Every failure belongs in the same audit record as successful actions, with the same fields. Failures pushed to a separate error log lose the context that makes them diagnosable, and the two systems drift out of alignment immediately.

Worth tracking as a rate over time:

• Failures by class. A rising ambiguous rate means the world contains cases your decision rules do not cover.
• Retry exhaustion rate. Rising means a dependency is degrading.
• Escalation rate, and time-to-resolution. Rising escalations with slow resolution means the agent is generating work rather than removing it.
• Partial completion frequency. Should be near zero. If it is not, step ordering is wrong.

Designing it, in order

1. Enumerate what can fail at each step: dependencies, permissions, data quality, ambiguity.
2. Classify each into the five classes above.
3. Set the response per class, not per step.
4. Set retry caps and a time budget, with backoff and jitter.
5. Order steps so irreversible actions are last.
6. Choose a partial-completion strategy per workflow and write it down.
7. Name the escalation owner per class, before deployment.
8. Design the escalation payload to carry all six elements above.
9. Test by breaking things. Take a dependency offline in a controlled environment. Failure handling that has never executed is untested code.

Step 9 is the one that gets skipped, and it is the only one that proves the rest work.

Where this sits

Failure handling is one of the eight readiness conditions in when not to use an AI agent. If the failure modes of a process are not understood well enough to enumerate, that is a strong signal the process is not ready for an agent — not because agents cannot handle failure, but because nobody can specify what handling it means.

The control model this belongs to is described on the agentic operations page, and the product being built around it is Barion Agents, which is not yet available.