Summary
- For an agent pilot to exist, it needs approval. To get approved, it needs a demo. And the agent that would work in production is precisely the one that gives the worst demo.
- An analysis of 73 real incidents shows what agents die of: banal tool and context failures. Plus the cause nobody records: the provider went down, or the policy filter changed, and there was no plan B.
- The survivors look alike: closed scope, explicit refusal, complete traces and proof.
- Evals are the agent's CI. The three questions are in section 5, answerable in one meeting.
1. The problem is the demo
The statistic that most agent pilots never reach production shows up in every survey, and it has circulated so much it became wallpaper. Wallpaper changes no decisions: everyone agrees and keeps doing the same thing.
So instead of repeating the statistic, it's worth looking at the premises. Picture this: a project for an agent to be deployed in area X with team Y. Looks like it will bring efficiency, cost reduction, scale… right. But how does that project get approved? To have any chance, including the chance to fail, it needs approval. To get approved, it needs a sponsor. The sponsor wants to see planning, an estimate, a timeline, some return number. Someone builds the deck, someone defends it in the meeting. And there's one thing that can't be missing.
A demo, of course. Live, preferably.
And the demo has its own laws. It runs on the happy path, with rehearsed data, on the test account, with the API in a good mood. It has about five minutes to convince busy people, so the more things the agent does in those five minutes, the better it plays its role. Nobody gets up from their chair for the closed-scope slide; the room gets up when the agent answers the customer, queries the CRM and books the meeting with nobody touching the keyboard.
That's the problem. The demo.
The criterion that decides whether the project is born has no relationship with the criterion that decides whether it survives. The same agent that would work in production is not the most attractive one in a demo. The agents that survive are precisely the ones that would give the worst demo.
The agent that shines in demos is a different animal. It's the WhatsApp bot that answers the customer, queries the CRM, generates the promo artwork, books the meeting and promises to handle everything. Ten skills in the presentation, and none of them has a success criterion, an owner or a test. When it hits production, it miswrites the CRM record, sends the artwork to the wrong customer, and when someone complains, nobody can say which of the ten skills broke first.
In the end, the room approves the agent that surprises. But production is the place where what survives is what behaves the same way every day.
2. What agents actually die of
On public data, the best available X-ray is an analysis of 73 production agent incidents, between January and May 2026, all in systems actually running.
The ranking of causes is surprisingly banal. A third of the incidents started at a tool call: the API changed, the contract broke, and the agent kept going as if nothing had happened. Another quarter came from poor-quality context, meaning the agent decided reasonably over wrong information. And 19% were planning failures, the big task broken into subtasks that didn't lead to the result.
The study's most valuable number is the cost of investigating: incidents without a decision trace took 4.2 hours on average to resolve. With instrumentation, under 1 hour.
The two biggest causes share a shape: the input failure is silly, and the damage comes from what the agent does after it, because it doesn't stop when something breaks. It improvises around the broken response and keeps the workflow going with corrupted context. In the data, 61% of context failures generated a second failure at another layer, with the original cause hidden behind it.
This is where the demo misleads the most. It shows how the agent behaves when everything works, and what decides its life in production is how it behaves when something arrives already broken.
There's also a cause of death that doesn't even show up in these statistics, because nobody records it as an agent incident: the provider went down. Most pilots run entirely on a single provider, and faced with the question "what happens if OpenAI goes down right now?", the usual answer is a retry policy or something of the sort.
Retry doesn't cover the real case. These models' policy filters are volatile: from one hour to the next, a legitimate prompt can get flagged as malicious, and that tends to happen in the small hours before the important presentation. The answer that holds is model fallback — with the alternate path's prompts versioned and tested like the primary's. Not trivial.
In that design, the agent's availability is the vendor's availability. The mitigation is one fallback line in the routing pointing at a second provider, but it has to exist before the outage.
3. The four traits of the boring agent
The agents that stay in production converge on the same design, and it is the opposite of the demo's.
The first trait is closed scope. One task with a success criterion you can check by looking. The triage agent triages, period. Every extra skill that impresses in the presentation is one more failure mode, waiting for the worst moment.
The second is explicit refusal. When the request is outside the domain, the agent returns it, forwards it or escalates to a human, instead of trying. Refusal is the cheapest protection there is and, curiously, it's the first thing enthusiasm cuts from the project, because in a demo it looks like a limitation.
The third is the complete trace. Every tool call logged, every decision reconstructible afterwards. It's what separates the 4.2-hour investigation from the sub-1-hour one, and what separates an incident review with facts from an incident review with opinions.
The fourth trait is having proof that it works, detailed in section 4.
Where boring has already won
The most-cited public cases of agents operating at scale are all hyper-specialized. The millions-of-lines ETL migration that shipped in two months, in a well-known digital bank case, was an agent making a single kind of change, with a known shape, and an engineer approving each one. The 30,000 applications migrated off old Java at a big tech ran in a transformation pipeline where tests were the acceptance gate. Neither promises to handle everything. Both do one thing, thousands of times, with verification built into the process.
And the closed scope opens an interesting door: the hyper-specialized model. A narrow task with a clear criterion is the terrain where a small model reaches the frontier model. That is what we measured in practice when swapping a proprietary LLM for an open 9B model distilled for the task: the bill dropped 36x. An agent that promises to do everything will never be able to use a model like that, because "everything" doesn't distill. The single-task agent can, and then the cost per run collapses, along with the unpredictability. As a bonus, a model that only knows how to do one thing is born with refusal built in.
4. Evals are the agent's CI
Nobody merges code without going through CI. Now consider: what happens between a change to the agent's prompt and production?
Often, nothing. The prompt that makes decisions in production gets edited; someone glances at it and off it goes. Swapping the model in the config follows the same path. And the surveys of engineering leaders confirm this isn't a detail: the missing evaluation shows up as the main blocker for agents reaching production, cited by 64%, ahead of governance and model reliability.
The minimum version that works looks like software testing, with one difference: since the model's output varies, the approval criterion is a hit rate, not exact equality.
In practice, it means building a suite of real cases, with inputs representative of what the agent sees day to day and the expected result specified. Adding the adversarial cases, which are precisely the broken inputs agents die on: the API that changed, the empty context, the out-of-scope request. Running that suite on every change to prompt, tool, model or context. And closing the loop with a simple rule: a production incident becomes a new case in the suite, so the agent that fell yesterday never falls the same way again.
Without this, every prompt tweak is a deploy without tests. With it, the agent gains what code gained twenty years ago: the freedom to change without fear.
5. The three questions
All three can be answered in one meeting, without asking around.
First: what does the agent refuse? Ask for the list of what it doesn't do. If the answer is "it's general-purpose" or silence, the scope doesn't exist. And without scope there's no success criterion, no possible test case and no damage limit. The refusal list is the most important design document an agent has.
Second: can you reconstruct why it did what it did yesterday? Pick one run from yesterday and try to reassemble the chain: what context went in, which tools were called, what each returned, what it decided with that. If at any point the answer is "we'd need to add logging", the operation is on the 4.2-hour side. Instrumentation only helps if it's done before the incident.
Third: what runs between a change and production? If the answer is "we test by hand with two or three examples", that's the equivalent of testing code by clicking around. It works until the day it stops working. The suite doesn't need to be born big. It just needs to be born before the next deploy.
The opposite also exists: internal prototype, low stakes, no access to anything irreversible, no need for all that preparation. This rigor pays off when the agent touches customers, money or production data. Before that, it just gets in the way of learning.
6. The charm is in the wrong place
The demo optimizes for surprise. Production rewards tomorrow's behavior being the same as today's, especially when the input arrives broken.
That's why the right question for evaluating an agent isn't what it can do. It's what it guarantees it won't do, and how that is known. The agent that answers that well is boring to demo and cheap to operate. The other one delivers a great demo and a terrible night.
How we help teams adopt AI
We work with engineering teams putting AI into the real development workflow, not as an experiment, but as an actual part of how the team ships.
That means choosing the right tools for the team's context, configuring them in a way that makes sense for the company's data policy, and making sure developers know how to use them in a way that genuinely increases productivity instead of adding friction.
If you have a development team and you're trying to put AI to work seriously, get in touch.