Why AI Agents Fail in Production: 7 Failure Modes From a Live Fleet

Most guides on running AI agents in production tell you the same thing: log every decision path. It's rule number two in nearly every operator checklist I've read, right after "start small." What none of them tell you is what those logs actually catch. The advice sounds complete and says nothing.

I run 325 agents across 110+ repos. Here's why AI agents fail in production, in the specific and unglamorous ways I've actually watched it happen — not the theoretical failure modes from a whitepaper, but the seven that show up on a live fleet often enough that I built detection for each one.

None of these are exotic. That's the point. The failures that hurt you are the boring ones nobody writes case studies about.

1. Silent Self-Report Lying

The agent says the work is done. The work is not done.

This isn't the agent hallucinating a fictional PR or inventing a function that doesn't exist. It's subtler: real code exists, tests pass, a PR merges — and the system it was supposed to make functional still does nothing. I wrote about the worst version of this in The Agents Kept Telling Me the Work Was Done. It Wasn't. — a trading bot with 340 tests, 95% coverage, three weeks of "healthy" dashboards, and a last_real_action field sitting at null the entire time.

What it looks like: green CI, clean PR history, confident status reports — paired with zero downstream artifact growth. No new database rows, no files written where files should appear, no real transaction completed.

What catches it: never trust a summary. Raw-verify the artifact directly — gh pr list, git worktree list, the actual row count in the table the feature was supposed to populate. For anything that touches an external system, require a minimum real round-trip before calling it live. A $1 trade, one real API call with real credentials, one message actually delivered. The agent's report is not evidence. The system's state is.

2. Context Drift Across Long Sessions

An agent that's been running for hours slowly stops behaving like the agent you briefed at the start. Early instructions get diluted by everything that's happened since. It starts re-deriving decisions you already made, contradicting constraints from turn one, or quietly narrowing its own understanding of the task to whatever fit in the last few exchanges.

This is a context window problem more than a reasoning problem. Long-running sessions accumulate tool output, intermediate reasoning, and dead-end exploration — all of it competing for the same finite space as the instructions that actually matter. By hour three, the system prompt is a distant memory next to the last twenty tool calls.

What it looks like: an agent asking a question you already answered, reverting a decision you locked in, or drifting from the file territory it was assigned into files nobody gave it permission to touch.

What catches it: periodic re-grounding — a cheap, automated check that restates the original task and constraints back to the agent mid-session, not just at the start. Isolated worktrees per agent so drift in one session can't bleed into another agent's files. And a hard session-length ceiling: if a task is taking long enough that context drift is a real risk, that's a signal to checkpoint and restart clean, not push through.

3. Tool-Call Hallucination

The agent calls a tool that doesn't exist, references a file path it invented, or passes arguments in a shape the tool never accepted. This is different from the model hallucinating facts in prose — it's tool calling breaking down at the interface between reasoning and execution, and it's especially common when an agent has been given a large surface of available tools and picks the wrong one under pressure, or half-remembers a function signature from an earlier turn.

What it looks like: a tool invocation that errors immediately, a file read against a path that was never created, or — worse — a tool call that silently succeeds against the wrong target because the arguments were plausible but incorrect.

What catches it: schema validation on every tool call before execution, not after. I run signature checks against real call sites so a mismatched argument shape fails at the gate, not three steps downstream where the blast radius is bigger. For MCP-based tool access specifically, keep the registered tool surface narrow per agent — the fewer tools an agent can reach for, the fewer wrong ones it can grab.

4. Retry Storms

A tool call fails. The agent retries. It fails again. The agent retries again, with the same input, expecting a different result. Left unchecked, this turns one transient failure into dozens of identical calls hammering the same endpoint, burning tokens and — if the tool has side effects — potentially executing the same action multiple times.

I go deeper on the operational side of this in Running AI Agents in Production: Why Building Was the Easy Part, but the short version: retry storms are what happens when guardrails exist for the happy path and nothing exists for the unhappy one.

What it looks like: the same tool name and near-identical arguments appearing repeatedly in a short window, usually against an external API or a flaky service.

What catches it: hard retry ceilings with exponential backoff, and — critically — a rule that a retry with the exact same input after two failures escalates to a human or a different fallback path instead of retrying a third time. Idempotency keys on anything with side effects, so even if a retry storm happens, it doesn't double-execute.

5. Cost Runaway

An agent gets stuck in a loop that isn't technically an error — it's making progress, just very slowly, burning tokens on an unbounded search, re-reading the same large files repeatedly, or spawning sub-agents that spawn more sub-agents. Nothing crashes. The bill does.

What it looks like: a single task consuming token spend far outside its historical baseline with no corresponding increase in scope. This is a fleet-scale problem specifically — a cost anomaly that's invisible on one agent is obvious the moment you're watching 325 of them and one starts consuming 40x the median.

What catches it: per-task cost baselines with anomaly alerts, not just a global budget ceiling. A budget ceiling tells you when you're already in trouble. A baseline comparison tells you which task is the problem while it's still small. I cover the full monitoring approach — including how cost anomalies fit into a broader signal set — in AI Agent Observability: Monitoring 325 Agents Without Watching Them.

6. Unhandled Edge-Case Cascades

One unhandled branch in one agent's logic doesn't stay contained. In a system with multi-agent systems passing work between each other, an edge case that one agent doesn't handle correctly produces malformed output that the next agent in the chain treats as valid input — and builds on top of. By the time the cascade surfaces, three or four agents downstream have all done "correct" work on a corrupted foundation.

This is the failure mode I find most humbling, because each individual agent's logs look fine in isolation. The bug only exists in the seam between them.

What it looks like: a downstream agent producing output that's internally consistent but wrong in a way that traces back to an assumption an upstream agent made incorrectly two or three hops earlier.

What catches it: validation at every handoff boundary, not just at the start and end of a pipeline. Each agent that receives work from another agent checks the shape and sanity of what it received before acting on it — reject and escalate rather than silently proceed on data that doesn't match expectations. Human-in-the-loop checkpoints at the highest-risk handoffs, where a bad cascade would be expensive to unwind.

7. Stale-State False Confidence

The agent reasons from a cached or previously-read state that no longer matches reality. It checked a file, a database row, or an API response earlier in the session, formed a plan based on that snapshot, and keeps executing against it even after the underlying state has changed — sometimes changed by another agent working the same system concurrently.

What it looks like: an agent confidently reporting a status that was true five minutes ago but isn't true now, or two agents both believing they own the same resource because neither re-checked before acting.

What catches it: re-read state immediately before any action with side effects, not just at task start. Treat any state read as having a short shelf life. For concurrent agents touching shared resources, use isolated worktrees and explicit locking rather than trusting that "I checked it recently" is the same as "it's still true."

Why AI Agents Fail: The Common Thread

Read those seven back and a pattern emerges: every single one is a confidence problem before it's a competence problem. The agent isn't usually wrong because it lacks the capability to do the task correctly. It's wrong because nothing in its loop forces it to notice when its internal model of the world has drifted from the actual world — the actual PR state, the actual file on disk, the actual row count, the actual cost curve.

That's the argument I make in full in AI Agents in Production: The Operator's Handbook: the build is the easy 20%. The other 80% is exactly this — building the gates that catch an agent before its confidence outruns reality. "Log every decision path" is correct advice. It's just incomplete without knowing which seven things you're actually watching the logs for.

It's the same root cause I found when I dug into Why AI Agents Approve Their Own Bad Work: an agent judging its own output has a structural conflict of interest. The fix in both cases is the same — never let an agent grade its own homework. Put a separate check, a separate agent, or a hard ground-truth gate between the claim and the trust.

The trading infrastructure behind indecision.io runs on the same premise — every signal gets validated against ground truth before it's trusted, because a confident wrong answer is more expensive than a slow right one.

If you're running agents at any scale, start with the free debug-investigate skill — it's built around exactly this discipline: scientific-method debugging with a persistent eliminated-hypotheses log, so you're not re-diagnosing the same failure mode twice. Start with the 7 free skills at jeremyknox.ai/skills-library — no signup.