Four Failure Modes in Production AI Agents (and the Telemetry That Catches Them)

TL;DR

Traditional software fails by crashing. AI agents fail by running. Every individual call looks healthy; the failure is in aggregate behavior. Four failure modes are emerging as named patterns in the FinOps practitioner community: Retry Storms, Context Starvation, Prompt Bloat, and Cost-per-Success Drift. Each has a specific telemetry signal that traditional observability misses. This post defines each one and explains what to watch for.

The structural observation

Traditional software fails by crashing. AI agents fail by running.

Most of what's hard about AI cost monitoring in 2026 is captured in that distinction. Traditional observability was built for the first kind of failure: alerts when error rates spike, dashboards when latency degrades. The second kind doesn't trip any of those signals. The agent is running. Every individual call looks healthy. Aggregate behavior is the only place the failure shows up.

It's the core reason monitoring AI agents in production needs a different playbook than monitoring web services: you're watching for anomalies in pattern, not anomalies in output.

The most sophisticated FinOps practitioners have started naming these aggregate-only failure modes. The four below are worth knowing by name.

A brief note on workload type

Before the failure modes, one piece of vocabulary that makes everything else easier.

AI workloads split usefully into two categories. Conversation workloads are single-shot: one input, one output, predictable cost, bounded behavior. Agentic workloads are multi-shot: chains of LLM calls, often with tool use, sometimes with retry logic. Cost is harder to predict, retry loops are possible, and failure modes are different.

The four failure modes below show up almost exclusively in agentic workloads. Conversation workloads have their own cost discipline questions, but they're closer to traditional capacity planning. Agentic workloads are where the operational intelligence work happens.

Failure mode #1: Retry Storms

The pattern: An agent or workflow retries the same failing operation repeatedly, consuming tokens without making progress. Sometimes the retry is in the orchestration layer (the workflow keeps re-invoking the same step). Sometimes it's inside the agent itself (the agent gets stuck in a reasoning loop trying to recover from a tool error).

Why traditional monitoring misses it: Each individual retry looks like a successful API call. The LLM returns a response. The tool returns a result. The system isn't erroring. From the per-call view, everything is fine. The failure only emerges at the trace level, where you can see the same step has happened seventeen times in two minutes.

The telemetry signal: Retry rate per trace, not per call. A healthy agentic workflow has a predictable maximum retry count for any given step. When the distribution of "retries per trace" develops a long tail (some traces have 5 retries, some have 50), you're seeing retry storms in real time.

A useful threshold: alert when more than 5% of traces in a rolling 15-minute window have retry counts above the workflow's intended maximum. The exact threshold depends on the workflow, but the principle generalizes.

A note from personal experience: I lived through one of these. A five-agent pipeline I'd built ran unattended for 10 days, generating 31,762 session files and 6,352 dispatch cycles. The dispatcher logic was sound; the agents were doing exactly what I'd built them to do. The retry pattern was structural. There was no error to catch, just a 30-second loop kicking off the full pipeline whether or not there was work to do. By the time I noticed, the bill had moved past what I'd budgeted for the quarter.

That experience is what put me on this set of failure modes in the first place.

Failure mode #2: Context Starvation

The pattern: An agent's context window gets consumed by tool calls, system prompts, retrieved documents, or conversation history, leaving insufficient room for the actual task. The agent still produces output. The output is just worse, because the model is reasoning with less working memory than it needs.

This is the failure mode most likely to show up as a quiet quality regression rather than a cost spike. The cost looks fine; the outputs get gradually less useful. Often the team notices because of customer complaints about degraded responses, not because of any operational alert.

Why traditional monitoring misses it: No errors fire. The agent completes its task. The latency is normal. The cost per call is even slightly lower (because there's less room for the agent to do expensive multi-step reasoning). Every per-call signal looks healthy.

The telemetry signal: Context window utilization over time, broken down by what's consuming the window. Three useful signals:

• System prompt growth: has your system prompt grown by 50% in the last quarter as features were added?
• Tool call output bloat: are tool calls returning more data than the agent actually needs?
• Retrieval context size: is your RAG pipeline pulling 12 documents when 3 would suffice?

A useful question to ask in a quarterly review: what percentage of our context window is actually being used for the user's task, versus consumed by infrastructure? Most teams find the answer is uncomfortable.

The term "Context Starvation" comes from the FinOps practitioner community, where it's becoming part of the working vocabulary for AI workload analysis. Worth adopting.

Failure mode #3: Prompt Bloat

The pattern: Prompts grow over time as features get added, eating tokens without delivering proportional value. Each addition seems reasonable in isolation: handle this edge case, add this guardrail, improve this output format. The aggregate is a prompt that's 4x its original size and produces output that's marginally better at best.

This is the silent cost driver in mature AI features. A prompt that started at 800 tokens grows to 3,200 over six months. Nobody noticed because each change seemed small. The cumulative effect is a 4x token cost on every call to that feature.

Why traditional monitoring misses it: There's no event to alert on. Each prompt change goes through normal code review. Each individual prompt is fine. The failure is the drift over time, which doesn't show up as an anomaly because it happens gradually.

The telemetry signal: Token count per call, tracked as a time series per feature. The shape that matters is the trend. A flat line is healthy. A slowly-rising line is bloat in progress. A step function is a feature change that meaningfully expanded the prompt, fine if intentional, worth investigating if not.

The most useful version of this dashboard segments by feature: "input tokens per call for the customer support agent, last 90 days." When that graph has a clear upward trend, you're watching prompt bloat happen in real time.

The term "Prompt Bloat" comes from the same FinOps practitioner conversation that's developing this vocabulary. It's a specific operational concept, not a generic complaint about verbose prompts.

Failure mode #4: Cost-per-Success Drift

The pattern: Workflows still complete. Outputs are still produced. The aggregate cost is even relatively stable. But the cost of one useful outcome has slowly increased, because more retries are happening, more outputs are being discarded by users, more sessions are being abandoned before completion.

This is the most subtle of the four failure modes and the one practitioners are starting to name most explicitly. The FinOps community is converging on terminology around this: "cost per success" and "cost per thought" capture the idea that the unit of analysis should be the successful complete trace, not the individual API call.

Why traditional monitoring misses it: Aggregate cost looks fine. Per-call cost looks fine. Even per-trace cost looks fine in isolation. The failure shows up only when you correlate cost with outcome, when you ask "of all the AI calls we paid for last week, what percentage actually produced output a user accepted or applied?"

The telemetry signal: Cost per successful trace, tracked over time. Requires three pieces of data: per-call cost (easy), per-trace aggregation (medium), and outcome attribution (hard, requires the application to emit signals about whether the output was accepted, rejected, retried, or abandoned).

The plumbing is the same tagging discipline behind per-customer cost attribution: once every call carries customer, feature, and outcome tags, cost-per-success is one query away.

The hardest piece is outcome attribution, which is why most teams don't track this yet. But the practitioners furthest along, the ones speaking at FinOps X about cost-per-thought and cost-per-success, are doing exactly this work. It's where the AI cost discipline is heading: cost per useful outcome is the unit-economics view of AI, not just another line on the invoice.

A useful starting question: what percentage of your AI spend produced output your customers actually used? Most teams can't answer this. The answer, when teams build the instrumentation to find out, is often uncomfortable.

Why these four matter together

Each failure mode has a specific telemetry signal. None of them trip any traditional observability alert. Together they describe a structural gap in how AI agents are monitored in 2026.

Three observations worth holding onto:

1. The failure modes are aggregate-level, not call-level. Every signal that matters here is about patterns over time, not single events. Traditional monitoring was built for single-event alerting. Operational intelligence for AI agents requires aggregate analysis.

2. The vocabulary is doing real work. Naming these failure modes makes them tractable. A team that says "we're seeing context starvation in the research agent" can have a focused conversation. A team that says "AI costs are up" can't.

3. The most sophisticated practitioners are already tracking these, mostly inside Datadog with custom dashboards. Sophisticated FinOps practitioners have built this. They're sharing it at FinOps X. They've developed the vocabulary. The teams who haven't built it yet aren't behind. They're representative of where most companies are. The state of the practice is bifurcated between teams who have the FinOps capacity to build custom monitoring and teams who don't.

What you can do about it

A few practical moves, in order of leverage:

1. Start with vocabulary. Adopt the terms (Retry Storms, Context Starvation, Prompt Bloat, Cost-per-Success Drift) in internal conversations. Naming the failure mode is the first step toward managing it.

2. Audit your existing observability for these specific signals. Do you have retry rate per trace, not per call? Context utilization breakdown? Token count per call tracked as a time series per feature? Cost per successful trace? If your existing tools can answer all four questions, you're ahead of most teams.

3. If you have a sophisticated FinOps practitioner, build this in Datadog or your existing observability stack. It's doable. The practitioners doing it publicly are documenting their approach.

4. If you don't, this is the gap that operational intelligence tools are emerging to fill. AIWatcher is one of them. We track these specific failure modes across both internal AI coding tools (Claude Code, Cursor, Codex CLI) and product-side AI features, with the vocabulary the FinOps community is developing already built into the dashboards. We're in design partner mode in 2026 with mid-market AI-native SaaS companies. Request access →

Closing

The teams that name failure modes manage them. The teams that don't keep getting blindsided by invoices.

The four patterns above are emerging as the named failure modes for production AI agents. They're not going away. They're going to multiply as agentic adoption scales. The vocabulary is being shaped in real time by the FinOps community. The teams paying attention are building the telemetry to detect them.

The teams that aren't paying attention will be the case studies in the next round of FinOps X talks.

Danny Lo is the founder of AIWatcher, the operational layer for AI agents. We track these failure modes across both internal AI tool usage and product AI features.