Short answer
AI agents rarely fail in production because the model is too weak. They fail because the task has no measurable finish line, the run is longer than the model can reliably handle, the agent grades its own work, and nobody built the exits, budgets and checks around it. Each of those has a known fix.
The demo went well. The agent read the ticket, wrote the code, ran a test and said it was done. Then it went into production, and within two weeks people stopped trusting it. It stopped halfway through jobs, reported success on work that didn’t run, and once spent an afternoon in a loop that nobody noticed until the bill came.
If that sounds familiar, the problem is usually not the model. In my experience the failures cluster into a small number of patterns, and almost all of them are about what surrounds the model: how the task is defined, how long the run is, who checks the result and where the exits are.
How often agent projects fail, and why the numbers are so bad
The headline figures are grim. In June 2025 Gartner predicted that over 40% of agentic AI projects will be cancelled by the end of 2027, and estimated that only about 130 of the vendors selling “agents” are genuinely agentic. The rest is agent washing: chatbots and RPA with a new label. MIT’s NANDA report on generative AI in companies found that about 95% of pilots showed no measurable effect on profit and loss.
The MIT report has a second finding that gets less attention and is more useful. Tools that companies bought from specialised vendors succeeded far more often than tools they built themselves.
I don’t read that as “never build”. I read it as: the in-house teams underestimated the part that isn’t the model. A vendor that has shipped the same workflow a hundred times has already paid for the retries, the checks, the permissions and the logs. A first internal build usually hasn’t. The nine failure modes below are that missing part.
Failure modes 1 to 3: the task itself is wrong
1. No measurable finish line. “Improve onboarding” or “clean up the billing module” are not tasks an agent can finish, because there is no state of the world in which they are done. The agent will stop when it feels done, which is a guess. Fix: every task gets acceptance criteria that a command can check. I wrote a whole piece on acceptance criteria an agent can’t talk its way around, and it is the single change with the biggest effect.
2. A task with no business owner. Gartner’s explanation for the cancellations is escalating costs, unclear business value and inadequate risk controls. Two of those three are not technical. An agent that automates a step nobody was waiting for gets cancelled at the first budget review, however well it works. Fix: start from a queue that already exists and already hurts, such as dependency bumps, flaky test triage or small tickets that sit for days, and measure the queue before and after.
3. A task that is too long for one run. This is the one people underestimate most, and METR’s measurements explain it well.
Why long agent runs fail more often than short ones
METR measures the length of task, in human working time, that a model can complete with a given probability. Their published numbers show a gap that matters a lot in production: the task length a model finishes half of the time is many times longer than the length it finishes four times out of five.
Read that chart as an engineer, not as a fan. If you want a job to succeed reliably, the honest unit of work is closer to the 80% number: an hour or so of human-equivalent work, not a day. A twelve-hour task handed to an agent in one piece is a coin toss. The same work cut into ten one-hour tasks, each with its own check, is a sequence of likely wins where failures are caught early and cheaply.
Fix: split work into tasks that fit inside the reliable horizon, give each one its own criteria, and commit between them so a failure costs one task, not the night.
Failure modes 4 to 6: the agent decides when it is done
4. Stopping halfway. The agent does a third of the job, writes a confident summary and asks whether you’d like it to continue. In an interactive session that is annoying. In production, where nobody is there to answer, the job just ends. I go through the causes and fixes in why coding agents stop halfway. The short version: completion is something the system checks, not something the agent declares.
5. Declaring victory early. Anthropic’s engineering team described exactly this in their write-up on harnesses for long-running agents. Later in a project, an agent would look at the existing progress and declare the job done while much remained, or mark a feature complete after a unit test or a curl call without checking it worked end to end. Their fix was a feature list in JSON with every item marked failing, where the agent may only change the passes field. That is a good pattern to copy: the list of what “done” means exists before the agent starts and the agent can’t rewrite it.
6. Grading its own homework. When the same model that wrote the code also judges it, it tends to agree with itself. The LLM-as-a-judge research by Zheng and colleagues lists self-enhancement among the known biases of model judges, next to position and verbosity bias. Fix: the reviewer is a different model, or at least a fresh context with no access to the writer’s reasoning, and it judges evidence such as build output and test results rather than the writer’s summary. More on this in why the writer can’t be the reviewer.
Failure modes 7 to 9: the harness has no walls
7. Too much access. OWASP’s Top 10 for LLM applications puts prompt injection first and excessive agency sixth. An agent that can read issue comments and also push to main, or read email and also send money, is one crafted paragraph away from doing something nobody asked for. Fix: least privilege per task, a sandbox or container, no production credentials in the agent’s environment, and a deny list for the commands that can’t be undone.
8. Loops with no exit. An agent retrying a failing test forty times is not persistence. It is a cost leak. Fix: hard limits on rounds, wall-clock time and spend, plus a “no progress in two rounds” rule that parks the run for a person instead of letting it spin.
9. Nobody can see what happened. When a run fails at 3 a.m., the question is what it did, in what order, and with which inputs. If the only record is the agent’s own final message, you can’t answer. Fix: keep the full transcript, the commands with their exit codes, the diff and the cost of every run, somewhere a person can read in the morning.
A table of failure modes and fixes
| Failure mode | What you see | Fix that holds |
|---|---|---|
| No finish line | Agent stops “when it feels done” | Acceptance criteria as commands that exit 0 or not |
| No owner | Project cancelled at budget review | Start from an existing, measured queue |
| Task too long | Success rate drops on big tickets | Split to roughly an hour of work each, commit between |
| Stops halfway | “Would you like me to continue?” | Stop check that blocks until criteria pass |
| Declares victory early | Features marked done that don’t work | Fixed feature list the agent can’t edit, end-to-end checks |
| Self-review | Reviewer agrees with every change | Different model or fresh context, judging evidence |
| Too much access | Unexpected writes, injected instructions | Least privilege, sandbox, no prod secrets |
| No exit | Runaway retries and cost | Round, time and spend limits, park on no progress |
| No record | Can’t explain a failure | Transcript, commands, exit codes, diff, cost per run |
What a production agent looks like when it works
Put the fixes together and a shape appears. A person, or a ticket system, supplies a task with criteria. The agent works on one bounded piece. The system, not the agent, runs the checks. A separate reviewer reads the diff and the evidence. Failures go back to the writer, and a run that stops making progress is parked with a clear note for a human.
The loop around a production agent
- Person
- Agent
- Automated check
Steps as text
| Step | What happens |
|---|---|
| 1. Task with criteria | Person — written before work starts |
| 2. Writer agent | Agent — one bounded piece of work |
| 3. System checks | Automated check — build, tests, criteria commands |
| 4. Reviewer | Agent — different model reads the evidence |
| 5. Merge or park | Step — limits decide when a person steps in |
| Loop | findings go back: back from step 4 to step 2 |
None of this is exotic. It is the same discipline we already apply to junior engineers and CI pipelines, written down so a machine can follow it. The Stack Overflow 2025 survey found that 66% of developers name “AI solutions that are almost right, but not quite” as their top frustration. “Almost right” is exactly what an agent produces when nothing outside it checks the last 10%.
The teams that get agents into production don’t have a better model than everyone else. They have a better harness, and they treat the agent as one component in a system with tests, limits and logs. I think the 40% cancellation forecast says more about how agents are being deployed than about what they can do, and that part is fixable today. If you want this set up for your team, write to me.
Questions
What is the most common reason AI agents fail in production?
The task has no checkable definition of done. Without acceptance criteria that a command can verify, the agent decides for itself when to stop, and that decision is often wrong in both directions.
Are AI agents reliable enough for production in 2026?
For bounded tasks with automatic checks, yes. METR’s data shows current top models complete tasks of roughly one to three hours of human work with about 80% success, so production systems should cut work into pieces of that size and verify each one.
Why does my agent say the task is done when it isn’t?
Because nothing outside the agent checks the claim. Make the system run the tests and criteria itself, and have a different model or a fresh context review the evidence rather than the agent’s summary.
Should we build our own agent or buy one?
MIT’s 2025 report found bought tools succeeded about twice as often as in-house builds. If you build, budget for the harness (checks, limits, permissions and logs), because that is where in-house builds usually fall short.