The Five Ways Production AI Agents Fail Quietly

The AI agent failure modes that matter in production share one property: they do not throw errors. Five account for most of the damage. Runaway loops, where an agent repeats the same tool call until a budget runs out. Wrong tool execution, where the action taken is not the action the model intended. Ungrounded answers, where the agent responds fluently despite empty or irrelevant tool results. Cost leaks, where context grows quietly until the invoice notices before you do. And prompt injection, where instructions ride into the agent through the data it processes. Every one of these can happen while your status codes stay green and your error rate stays flat, which is why teams usually meet them through a customer complaint rather than an alert. Here is what each looks like and what actually catches it.

What are the five failure modes?

1. Runaway loops. An agent decides the answer was not good enough and tries again, identically, and again. Openlayer's failure-mode analysis describes the mechanics: "an agent stuck in a retry loop keeps issuing the same tool call because it has no mechanism to recognize that the call already failed", and warns that "a looping agent may never throw an error while burning compute on semantically identical retries".

2. Wrong tool execution. The gap between what the model requested and what your code ran: a routing bug, a permissioning slip, an over-broad tool schema. The transcript reads reasonably; the action was wrong. This one worries security teams most because it is where "the AI deleted something" incidents live.

3. Ungrounded answers. A tool returns HTTP 200 with an empty or malformed payload, and the agent answers anyway. Openlayer again, precisely: "without explicit validation on the return object, the agent treats a failed retrieval as a successful one and builds subsequent reasoning on missing data". The same analysis puts tool-calling failures at 3 to 15 percent of production calls, with the silent kind the most damaging because nothing surfaces for review.

4. Cost leaks. Not one expensive run but a slow slope: chat history appended here, documents pasted into a system prompt there, until the same task costs many times what it did at launch. User-visible behavior is identical, so nothing but per-run cost attribution catches it.

5. Prompt injection through the data channel. The attack does not arrive in the chat box; it arrives inside a ticket body, an email, a scraped page the agent was asked to summarize. Galileo's failure-modes guide notes research showing injected instructions can even survive session restarts, which makes "we reviewed the prompt" a weak defense on its own.

I wrote a less sober version of this list, with the failures played as relationship red flags and each paired with the trace evidence, in Your AI Agent Has the Same Red Flags as Your Ex. Same five failures; this note is the reference card.

Why doesn't normal monitoring see these?

Because normal monitoring watches the transport layer and these failures live in the content. A loop is eight successful requests. A wrong tool call is a 200. An ungrounded answer is a 200 with fluent text. A cost leak is thousands of individually reasonable runs. An injection is a string inside a payload your logging pipeline faithfully stored and nobody read. Openlayer's practical advice for loops generalizes to all five: you need signals like step counts, output similarity, and content-level checks, "not only latency or error-rate metrics". Governance is heading the same direction; Galileo cites Gartner's prediction that half of agent deployment failures through 2030 will stem from insufficient runtime governance rather than model quality.

What catches each one?

Loops: trace-level visibility with spans grouped by tool name, so eight identical calls read as a shape, plus a hard step budget. Wrong execution: log requested tool next to executed tool and alert on mismatch. Ungrounded answers: a groundedness evaluation that scores each reply against what the tools actually returned; I covered how those judges work in LLM Evals Explained for Product Leaders. Cost leaks: token counts attributed per run and per customer, watched as a trend. Injection: scan tool outputs, not just user input, and run an injection evaluator over the tool trace so compromised runs are filterable instead of eyeballed.

None of this requires a platform on day one. It requires deciding that content-level evidence is part of production readiness, the argument I make at full length in the essay above. If you want it done for you, this is my Agent Trust Sprint: audit, failure analysis on real traffic, and 3-5 evaluations left running, 2 weeks at about 4 working days, EUR 2,400 fixed.

FAQ

Which failure mode is most common? Tool-related failures, by most published accounts, with the silent variant (success status, empty payload) doing the most damage per incident because nothing flags it.

Do these apply to plain chatbots, or only agents? Three of the five apply to any LLM feature: ungrounded answers, cost leaks, and injection via retrieved content. Loops and wrong tool execution need tools to exist, so they arrive the day you add tool calling.

Can guardrails prevent all five? Input guardrails help with injection and little else. The other four are behavioral, and you catch behavior with observability and evaluations, not filters. Prevention and detection are complements, not substitutes.

What is the single first thing to instrument? One full trace per run: every tool call with arguments and results, in order, with token counts. Four of the five failures become visible from that one artifact, and the fifth (cost) needs only the counts summed over time.