AI Agent in Production: What Breaks First
An AI agent that passes every test can still break in production for five specific reasons, almost never tied to the model itself. The checklist to catch them before launch.
What breaks first when an AI agent goes into production
Direct answer: the first point of failure is almost never the language model itself, it is the integration with the existing information system. An agent that performs flawlessly on a clean test set fails in production because it meets an API that changed shape, an authentication token that expired, or a database that turned out less consistent than expected. The rest of this article walks through the five failure points we see most often on client engagements, in the order they tend to appear, and the checklist that catches most of them before launch.
An agent that clears every internal benchmark with a high score can still lose a meaningful share of its reliability in the first weeks of production, simply because a real environment never has the cleanliness of a test environment. That is not a failure of the model's intelligence. It is a failure of the engineering built around it.
The five failure points, in the order they appear
Each failure point tends to trigger the next one. Separating them helps you know where to look first once an agent starts behaving unexpectedly.
1. Integration with the information system
Most of an agent's value comes from acting on real systems: a CRM, an inbox, an ERP, a ticketing queue. These are also the least tested components, because they get built last. In production, an API changes its response format without notice, a token expires on a Sunday night, a rate limit trips during a traffic spike. Every integration adds one more failure mode to the full chain. According to a 2026 survey reported by Smartpoint, information-system integration is still cited by 46% of companies as the first obstacle to production, ahead of cost (43%) and data quality (42%). None of this shows up in a pilot built against a handful of hand-picked test accounts: it only surfaces once the agent meets the full variety of records a real information system accumulates over years.
2. Data quality and freshness
An agent connected to a stale knowledge base answers confidently from information that is simply wrong. This is the most dangerous failure mode because it produces no visible technical error: the agent keeps answering, just with outdated or incomplete facts. Hybrid search, combining keyword and vector retrieval, narrows the problem but never removes it if the source itself is not kept current. A common trap for smaller companies is indexing documentation once, at launch, and forgetting to resync it once the agent is live: within a few months the agent is confidently quoting pricing, deadlines or procedures that changed long ago.
3. A context window that overflows
An agent built on the ReAct pattern often chains five to fifteen cycles before delivering a result, each one adding text to the context window. Past a certain volume, the model loses track of instructions given early in the conversation, a phenomenon documented as "lost in the middle". The fix is not a bigger context window. It is reducing what gets injected into it: relevance upstream rather than volume. Summarising older turns instead of keeping them verbatim, and recalling only the facts relevant to the current step, prevents most of the drift seen on long conversations.
4. Missing execution guardrails
Without a queue, an agent collapses at the first traffic spike. Without a retry strategy, it gives up on a transient error that would have resolved itself thirty seconds later. Without cost controls, a poorly bounded loop can multiply model calls and produce an unexpected bill within hours. Queueing, retries and budget controls are usually the first pieces of infrastructure missing from a prototype that has never met production. They are also the least visible during a sales demo, since a demo by construction runs on low volume and a favourable set of cases, which is exactly what makes them easy to underestimate before the first real traffic spike hits.
5. A governance gap
When an agent gets something wrong, someone needs to be able to explain why and fix it. Without a decision log, and without a clearly named business owner, the error repeats itself because no one has the mandate to correct it. This is often the last failure point to surface, and the most expensive to retrofit, because it is organisational rather than technical. A team that discovers this gap after an incident loses valuable time reconstructing, after the fact, who should have signed off on what: better to settle it before the first deployment than during a crisis meeting.
The metrics that reveal a failure before the user does
Uptime and average latency, inherited from classic application monitoring, are not enough to watch an agent: it can respond fast, with no server error, and still produce a wrong result or the wrong action. Four complementary metrics matter more. The failure rate per tool call, tracked separately from overall uptime, reveals integrations degrading before a user ever complains. An abnormal retry rate signals a loop starting to misbehave. Cost per successful task, rather than total spend, catches drift before it shows up on the monthly bill. Finally, a small sample of responses reviewed by a human every week remains the only reliable way to catch a drift in correctness that technical metrics alone never capture. None of these four require expensive tooling to start: a spreadsheet updated weekly, populated from the agent's own logs, is enough for the first few months of production.
Symptom, root cause, fix
The table below lists the symptoms we see most often on engagements, matched to the fix that usually resolves the problem at the root rather than the surface.
| Symptom observed | Likely root cause | Fix |
|---|---|---|
| Correct in testing, wrong in production | Production data differs from the test set | Evaluate on a real sample, not only a synthetic one |
| Agent slows down then falls over during a spike | No queue, no asynchronous processing | Decouple intake from processing with dedicated workers |
| Model bill doubles with no explanation | Unbounded loop or no per-user budget | Token quotas and automatic circuit breakers |
| Agent claims an action it never performed | No verifiable decision log | Trace every tool call and every decision |
| No one knows who fixes a recurring error | No named business owner | A business-side owner, not only a technical one |
The checklist before going to production
None of the following steps require a large team or a long timeline. Most take a day or two to put in place, and each one removes an entire category of the failures described above. In order, the steps that cut the most risk of a production failure.
- Scope the task narrowly, with clear inputs and outputs, rather than leaving it open-ended.
- Test against a sample of real production data, not only a clean synthetic set.
- Put a queue and asynchronous processing in place before the first traffic spike, not after.
- Define a retry strategy that distinguishes recoverable errors from permanent ones.
- Set token quotas and automatic circuit breakers per user or per task.
- Log every decision and every tool call, not only the errors.
- Name a business owner for the agent, separate from the team that built it.
- Plan a fallback to manual processing for when the agent steps outside its scope.
When an AI agent is not the right choice
An agent earns its keep when a task varies enough to require reasoning, while staying bounded enough to be verified. Outside that zone, it is usually not the right tool. A repetitive task with fixed rules and low volume is better solved with classic automation, cheaper to build and easier to audit. Conversely, a high-stakes decision that is hard to verify after the fact, or one bound by strict traceability requirements, keeps a human in the loop for longer than most product demos suggest. For a small accounting or legal practice, that means, concretely: automate the sorting and preparation of a file, but leave the final validation to a named person, rather than delegating the decision itself to the agent. The most reliable signal: if no one in the organisation can explain an automated decision after it happened, the agent is not ready for that scope, whatever it scored on a benchmark.
What we see on engagements
At Tesseract Studio, four products currently run in production, delivered by engineers who work embedded with the client rather than remotely against a fixed spec, the approach we detail in our article on the Forward Deployed Engineer. The pattern holds across engagements: failure points are almost never in the model chosen, but in the engineering around it, queues, logging, business ownership. That is also what separates a prototype that impresses in a demo from a system that still holds up a year later. Treating these five failure points as project risks, on the same footing as budget or deadline, rather than as technical details to settle later, directly changes the odds that the agent still holds up past the first few weeks. You can look at the detail of our work or browse all our articles on the topic.
Frequently asked questions
How long before an AI agent breaks in production?
There is no fixed timeline: it depends on traffic volume and how varied the real cases are. In practice, the first failures tend to appear within the first two to four weeks, once real traffic exceeds what testing actually covered.
Do we need a full agent or would simple automation do?
It depends on how much the task varies. A fixed-rule, low-volume task is usually better solved with classic automation. An agent earns its place when the task varies enough to need reasoning while staying verifiable.
Does RAG alone prevent hallucinations in production?
No. RAG reduces the risk by connecting the agent to real data, but it does not remove it if the knowledge base itself is not kept current or if retrieval returns passages out of context.
Who should own an AI agent's errors inside a company?
A business-side owner, separate from the technical team that built the agent. That person needs to be able to explain an automated decision and trigger a correction, not only the team that shipped the project.
If an AI agent passes every internal test, is it ready for production?
Not necessarily. High scores on an internal benchmark guarantee little against real data, changing integrations and unplanned traffic spikes. Only a period of production observation, with guardrails active, confirms readiness.
