Agents that demo beautifully collapse in production for reasons that have almost nothing to do with model intelligence. Ask why AI agents fail in production and the honest answer is usually engineering: arithmetic nobody did, errors nobody classified, and interfaces nobody versioned. Here are seven causes worth designing against, in rough order of how often they bite.
The arithmetic that sinks more agent projects than any model limitation. A workflow where each step succeeds 95% of the time completes end-to-end about 77% of the time at five steps and 60% at ten. Nobody set out to build a system that fails four times in ten — they built ten steps that each looked fine in isolation.
The fix is architectural, not a better prompt: fewer steps, checkpoints that let a run resume rather than restart, and per-step validation that catches a bad intermediate before it propagates. Measure per-step reliability and multiply it out before you ship. If the product of your steps is unacceptable, the design is wrong regardless of how good the model gets.
An agentic loop accumulates history. By turn thirty the context is dominated by its own prior output, the original instruction has scrolled into the middle where attention is weakest, and the model is now reasoning about its earlier reasoning. Behaviour degrades gradually, which makes it hard to spot — there is no error, just a slow loss of the thread.
Practical defences: re-inject the objective every N turns rather than trusting it to survive, summarise old history aggressively instead of carrying it verbatim, and cap loop length with an explicit give-up path that escalates to a human. A loop with no termination condition is not autonomy, it is a runaway process with a token meter attached.
A single expired key or an un-entitled model produces a wall of failures that no retry loop can fix, and the retry loop will try anyway — for weeks, if nobody is watching the right dashboard. Worse, if your system learns anything from outcomes, those failures teach it the wrong lesson.
We have this on record in our own telemetry: across 1,469 logged model calls in the 89.9 days to 9 August 2026, 345 were HTTP 403 responses from one provider lane, and 756 more failures carried no error class at all. Not a model problem. A configuration problem wearing a model problem's clothes. The taxonomy that prevents it is in LLM API error codes explained; the rule is that auth-class failures trip a circuit breaker and alert a human rather than entering the retry pool.
The diagnostic that finds most of this in an hour: group last month's failures by error class. If the largest bucket is "unlabelled," you do not have a reliability problem yet — you have an instrumentation problem, and it is hiding the reliability problem.
Agents call tools, tools are APIs, and APIs change. A field gets renamed, a required parameter is added, an endpoint starts returning a wrapped object instead of a bare array. The agent's tool definition still describes the old shape, so it constructs a call that is now invalid — and being a language model, it will often respond to the resulting error by trying a plausible variation rather than surfacing the problem.
Treat tool schemas as versioned contracts with contract tests that run in CI. If your agent's tools are not covered by tests that would fail when the upstream API changes, you will discover schema rot from a user complaint. The pre-production disciplines are in the agent testing guide.
The agent returns a confident, well-formatted, entirely wrong answer. Status 200. No alert. The number was transposed, the clause was invented, the document it claimed to read was never fetched. Every monitoring system in the world reports this as a success, and the user acts on it.
The only detection method is sampling: pull a fixed slice of outputs weekly and grade them against ground truth by hand. Ten a week is enough to establish a trend. Teams that skip this are measuring whether their HTTP client works, and calling it reliability — see the six metrics that matter.
Retries are standard practice, and standard practice becomes dangerous the moment an agent can send email, charge a card, create a ticket, or post to a channel. A timeout on a call that already succeeded server-side, followed by a retry, means the action happens twice. Users experience this as duplicate invoices and double-sent messages, and they do not forgive it quickly.
Every side-effecting tool needs an idempotency key derived from the task, and the runtime needs to distinguish "this failed" from "I did not hear back." Those are different states and conflating them is what produces the duplicates.
Multi-step agents fail halfway through, having already changed three things. If your compensating actions exist only as a design intention, the half-completed state becomes a manual cleanup job — usually done by whoever is on call, at speed, under pressure. Test the rollback path deliberately: kill the agent mid-run in staging and see what it leaves behind. The answer is rarely what the design document says.
Underlying most of these is a single principle worth stating plainly: run the thing rather than reading the roadmap. A design doc describes intent; an exit code describes reality. Most of what is broken in an agent system is visible within an hour of actually executing its own self-tests and grouping its own errors — and invisible indefinitely to anyone who only reads the code. For the deployment-side controls, see how to deploy an AI agent.
Would a better model fix these? Mostly no. Compounding error, schema rot, missing idempotency and untested rollback are properties of the system around the model. A stronger model raises per-step success slightly and leaves the structural failure modes exactly where they were.
What is the highest-value fix if we can only do one? Labelled failure classes on every error path. It is cheap, it converts an opaque failure rate into a ranked to-do list, and it usually reveals that one configuration issue accounts for the bulk of the problem.
How many steps is too many for one agent? There is no universal number — do the arithmetic with your own measured per-step rate. If five steps at your reliability produces an unacceptable end-to-end rate, the answer is to split the workflow, add checkpoints, or insert a human, not to hope the model improves.
Run the diagnostic this week: group last month's agent failures by error class and multiply your per-step success rate across your workflow. If you want a runtime that labels failures for you and writes them to a database you own, join the QADIR OS early-access list.