AI agent error handling is not one decision, it is four, run in a fixed order: retry, repair, degrade, escalate. Most broken agent deployments skip a stage. They either loop on a dead prompt until the API bill notices, or they ship nonsense straight to a client because nobody built an exit ramp. The order matters because each stage costs more than the last, and paying for stage three when stage one would have worked is how pilots quietly die.
AI agent error handling starts with retry, because retry is cheap
A plain retry, same prompt, same inputs, fixes a surprising share of bad outputs, because a lot of model nonsense is just noise: a truncated response, a malformed JSON brace, a timeout that returned a partial string. None of that is a reasoning failure. It is infrastructure jitter dressed up as model failure, and you solve it the same way you’d solve a flaky network call. Retry twice, no more. If the same call fails the same way three times in a row, the problem is not transient and retry will not fix it. I’ve watched teams retry five or six times on a prompt that was deterministically wrong, burning tokens on a coin that was never going to land differently.
Repair means naming the failure before you ask again
Repair differs from retry because you change the input, specifically by telling the model what it got wrong. If you have a schema and the output didn’t validate, say which field failed and why, not “try again.” This is where structured output pays for itself: when the contract is written down as a real structured output contract, the validator can hand back a precise error, and a model can act on a precise error. A vague “that wasn’t right” produces another vague answer. The repair prompt itself matters too, and the discipline for writing one is the same discipline covered in prompting for reliability: name the failure mode explicitly, don’t trust the model to infer what you meant. Repair also gets two attempts, not more. If the model fails the same validation twice after being told exactly what broke, it will not get there on a third try, it will produce a different wrong answer with the same confidence.
Degrade before you escalate
Degrading means falling back to a simpler, more deterministic path instead of handing the problem to a person immediately. This is the stage people skip because it requires building a second, boring version of the task in advance, and nobody wants to write the dumb fallback when the smart path usually works. But that fallback is what keeps an agent workflow usable at 2am when nobody is watching. Concretely: if a model can’t produce a structured summary, fall back to returning the raw input with a flag, not a fabricated summary. If an extraction step can’t reliably assign a category, default to “uncategorized” rather than guessing. The fallback should be visibly worse, never silently wrong. A client update that says “draft unavailable, see raw notes” is honest. A client update that confidently states the wrong number is not, and that gap is exactly where model hallucination does the most damage, because it looks identical to a correct answer.
Escalation is a design decision, not a safety net
Escalating to a human only works if someone already knows they’re getting the ping, and what they’re expected to do with it. Human-in-the-loop escalation that dumps a raw error into a Slack channel nobody owns is not escalation, it’s noise with extra steps. Before you build the escalation path, decide who receives it, what context they get, and what “handled” looks like. This is also the point to ask whether you’ve built an agent at all, or a pipeline wearing an agent costume: the agent or workflow test is worth running here, because a true agent making a judgment call needs a different escalation design than a fixed pipeline that just hit a branch it wasn’t coded for.
The limits: when to stop pulling the lever
Every stage needs a hard cap, enforced in code, not in good intentions. Two retries, two repairs, one degrade attempt, then escalate. No exceptions, no “just one more try because this feels close.” The failure mode that actually costs money isn’t the model being wrong, it’s a system that keeps paying to ask the same wrong question. If you’re seeing the same input fail repair twice a week, that’s not a retry problem anymore, it’s a schema or prompt design problem, and the fix belongs upstream, not in another loop.