Why most AI agents fail in production
The demo works, the pilot stalls, the rollout quietly dies. Four failure modes we see in almost every agent project — and what a system that survives contact with real users looks like.
Every agent project we inherit has the same origin story. Someone built a demo in a weekend, it did something genuinely impressive, and the room agreed it should go live. Six months later it is still not live.
The gap is not model quality. It is that a demo optimises for one path through the system and production has to handle all of them.
1. No evaluation harness
Teams ship agents the way they ship marketing sites: look at it, seems fine, deploy. Then a prompt changes and nobody can say whether the system got better or worse.
Before any agent goes near a user, you need a fixed set of cases with known-good outcomes and a script that runs them on every change. It does not have to be sophisticated. It has to exist.
If you cannot measure a regression, you are not maintaining a system. You are maintaining a mood.
2. Tools that lie about failure
An agent is only as reliable as the tools you hand it. The most common bug we find is a tool that returns a cheerful string when it has actually failed:
// The model has no way to know this went wrong
async function getInvoice(id) {
try {
return await db.invoice.find(id)
} catch {
return "No invoice found"
}
}The model reads that as a fact about the world and confidently tells the customer their invoice does not exist. Tools must distinguish "no result" from "I broke", and the agent must be told what to do with each.
3. Unbounded loops
Give a model a tool and a goal and it will happily try eighty times. Every production agent needs a step budget, a wall-clock timeout, a cost ceiling, and a defined behaviour when it hits one — usually handing off to a person with the context it gathered.
4. No place to put the blame
When an agent does something wrong, someone has to be able to open a trace and see what it saw, what it called, and why. Systems without that observability do not get debugged; they get switched off.
What survives
- A narrow, well-specified job rather than a general assistant
- Tools with honest error states and tight schemas
- Hard limits on steps, time, and spend
- Traces for every run, kept long enough to investigate complaints
- An eval suite that runs before anything ships
None of it is exciting. All of it is the difference between a demo and a system.
