Your AI agent nailed the demo. It answered questions, called tools, handled follow-ups. The CEO was impressed. Engineering gave the thumbs up. You shipped it.

Two weeks later, a customer reports that the agent recommended deleting their entire project folder. Another ticket: the agent spent 47 API calls trying to parse a CSV that didn't exist. Your monitoring dashboard - if you have one - shows that 30% of conversations end with the agent apologizing for something it can't do.

This isn't a hypothetical. Gartner projected that by 2028, at least 25% of enterprise AI agent projects will fail due to poor design or inadequate governance. From what we've seen building production agents, that number is conservative for teams that skip the failure-mode analysis.

Here are the seven ways agents actually break, how to catch each one, and what to do about it.

1. Tool Call Loops: The $200 Mistake

The most expensive failure mode is also the most common. An agent decides it needs to call a tool, the tool returns an unexpected result, and the agent tries again. And again. And again.

This happens because LLMs don't have a built-in concept of "giving up." If you've told the agent to "search until you find the answer," it will search until you run out of money or hit a rate limit.

Real pattern we see repeatedly: An agent calls a search API, gets zero results, rephrases the query slightly, gets zero results again, rephrases again. Fifty iterations later, you've burned through your API budget for the day.

Detection:

  • Track iteration count per agent run. Anything above 10 iterations for a single user request deserves investigation.
  • Monitor cost per execution. Alert when a single run exceeds 3x the rolling median.
  • Log the full tool call sequence. Repeated identical or near-identical calls are the signature.

Fix:

  • Set a hard iteration cap. We typically use 5-8 for most tasks, 15 for complex research tasks. When the cap hits, the agent returns what it has with an honest "I couldn't complete this fully."
  • Implement cost circuit breakers. If a single execution exceeds a dollar threshold, kill it.
  • Add a deduplication check: if the agent is about to make a tool call identical to one it already made, force it to either change approach or stop.

2. Context Window Overflow: The Silent Forgetting

This failure mode is insidious because there's no error message. The agent doesn't crash. It just gets... dumber.

Every tool call result, every conversation turn, every retrieved document goes into the context window. When the total exceeds the model's limit, the provider silently truncates from the beginning. That's where your system prompt lives. That's where the user's original instructions are.

Chip Huyen's analysis of AI engineering pitfalls flags this directly: teams build agents that work perfectly in 3-turn conversations and completely fall apart at turn 15 because the model has lost its instructions.

What this looks like in production:

  • The agent stops following its persona or safety guidelines mid-conversation
  • It contradicts information it provided earlier
  • It starts hallucinating tool capabilities it doesn't have
  • It "forgets" constraints the user set at the beginning

Detection:

  • Track token usage per conversation. Alert when total context exceeds 70% of the model's window.
  • Run a "system prompt echo" test: periodically ask the agent to summarize its own instructions. If it can't, context has been truncated.
  • Monitor answer quality by conversation length. If quality drops after turn N, you've found your threshold.

Fix:

  • Implement aggressive summarization. After every N turns, compress the conversation history into a summary and replace the full history.
  • Pin your system prompt. Some frameworks let you mark tokens as non-evictable. Use this feature.
  • Split long tasks into sub-agents with fresh context windows. An orchestrator agent delegates to specialist agents that each start with a clean context.
  • Trim tool results ruthlessly. If a search returns 10 results with full snippets, summarize before feeding to the agent.

3. Hallucinated Actions: When the Agent Invents Capabilities

This is different from standard LLM hallucination (making up facts). Hallucinated actions happen when the agent invents tool calls that don't exist, passes invalid parameters to real tools, or takes actions the user never authorized.

A detailed analysis from Galileo documents this pattern: agents will sometimes generate plausible-looking but completely fabricated API calls, especially when they're trying to accomplish a goal and their available tools don't quite fit.

The business risk is enormous. A chatbot that makes up a fact is embarrassing. An agent that makes up an API call and sends a real email, deletes a real file, or modifies a real database record is a liability incident.

Detection:

  • Validate every tool call against a strict schema before execution. Don't trust the model to generate valid JSON.
  • Log all attempted tool calls, including ones that fail validation. The pattern of attempted-but-blocked calls reveals what the agent is "trying" to do.
  • Run a red-team evaluation where you deliberately ask the agent to do things outside its capability set and verify it declines gracefully.

Fix:

  • Whitelist available tools explicitly. The agent should never be able to reference a tool that isn't in its tool list.
  • Add a confirmation step for destructive actions. Any tool call that writes, deletes, or sends should require explicit user approval.
  • Use typed tool definitions with strict parameter validation. If a tool expects an integer and the agent sends a string, reject it before execution.

4. Eval Blindness: Flying Without Instruments

Most teams building AI agents have no systematic way to know if their agent is getting better or worse. They rely on vibes. "It seems to be working fine." "Users aren't complaining."

This is like running a web application without error tracking or performance monitoring. You don't know it's broken until a customer tells you - and by then you've been broken for days.

Hamel Husain's work on LLM evaluation makes the point forcefully: generic metrics like ROUGE scores or cosine similarity tell you almost nothing about whether your agent actually works for your use case. You need domain-specific evals that test your specific failure modes.

What eval blindness looks like:

  • You change a prompt and have no idea if it made things better or worse
  • You upgrade to a new model version and cross your fingers
  • A customer reports a failure that's been happening for weeks
  • You can't answer the question "what percentage of agent interactions succeed?"

Detection: If you can't answer these three questions, you have eval blindness:

  1. What is your agent's success rate on its core task?
  2. How did that number change after your last prompt update?
  3. What are the top 3 failure categories this week?

Fix:

  • Build a golden test set of 50-100 real conversations covering your known failure modes. Run it on every change.
  • Implement trace-level logging so you can replay exact failure sequences. LangSmith, Braintrust, or even a custom solution - the tool matters less than having it.
  • Spend 60-80% of your development time on error analysis, not feature building. Look at the failures. Categorize them. Fix the most common ones first.
  • Track a single north star metric: task completion rate. Not "the agent responded" but "the agent accomplished what the user needed."

5. Cost Spirals: Death by a Thousand API Calls

Agent architectures are inherently more expensive than simple prompt-response patterns because every "thinking step" is an API call. A single user request might trigger 5-15 LLM calls (planning, tool use, reflection, summarization), each of which costs money.

This compounds with the tool call loop problem, but it's also a standalone issue. Even agents that work correctly can be prohibitively expensive if the architecture isn't cost-aware.

The math that surprises people: An agent that makes 8 LLM calls per request at $0.01 per call costs $0.08 per interaction. At 10,000 interactions per day, that's $800/day or $24,000/month - just in LLM costs, before infrastructure.

The New Stack reported that uncontrolled costs are among the top reasons AI agent projects get killed, even when the agent technically works.

Detection:

  • Track cost per conversation, not just total monthly spend. The distribution matters - a few runaway conversations can dominate your bill.
  • Set up anomaly detection on per-request costs. If the 95th percentile suddenly doubles, investigate.
  • Monitor model usage by endpoint. You might be using GPT-4 for tasks that GPT-4o-mini handles fine.

Fix:

  • Route by complexity. Use a cheap, fast model for classification and simple responses. Reserve expensive models for complex reasoning steps. Martian's research on model routing shows this can cut costs 40-60% with minimal quality impact.
  • Cache aggressively. If two users ask similar questions, the second one shouldn't trigger a full agent run.
  • Set per-user and per-conversation cost caps. When you hit the cap, degrade gracefully to a simpler (cheaper) response path.
  • Review your agent's "thinking out loud." Many frameworks include chain-of-thought tokens in the API call. If you're paying for reasoning tokens that the user never sees, consider whether you can use a structured output approach instead.

6. Silent Data Drift: The Slow Rot

Your agent works perfectly on launch day. Three months later, it's failing 20% of the time and nobody can figure out why. Nothing in your code changed.

The problem: everything around your agent changed. The APIs it calls updated their response format. The knowledge base it queries has new entries with different structure. User behavior shifted as they learned what the agent can and can't do. The underlying model got a minor version bump that changed its behavior on edge cases.

Shreya Shankar's research on production ML systems documents this pattern extensively: the operational challenge of LLM applications isn't the initial build, it's maintaining quality over time as the world changes around your system.

Detection:

  • Run your eval suite on a schedule, not just on code changes. Weekly is the minimum. Daily is better.
  • Monitor tool call success rates over time. A gradually increasing failure rate on a specific tool often means the external API changed.
  • Track user satisfaction signals (explicit ratings, conversation abandonment, retry rates) and correlate with time.
  • Version-pin your model and test thoroughly before upgrading.

Fix:

  • Treat your agent like a living system that needs continuous monitoring, not a feature you ship and forget.
  • Build automated regression tests that run against live APIs, not mocked responses.
  • Implement contract testing for every external dependency. If an API's response schema changes, your tests should catch it before users do.
  • Schedule quarterly "agent health reviews" where you sample recent conversations and evaluate quality manually.

7. Missing Guardrails: When the Agent Goes Off-Script

This isn't about prompt injection attacks (though those matter too). This is about the everyday case where a well-intentioned agent does something you didn't anticipate because you didn't define the boundaries of its behavior.

An agent told to "help users with their accounts" might interpret that as permission to change account settings, close accounts, or access accounts that belong to other users. An agent told to "find relevant information" might decide that reading the user's email is a valid way to find relevant information.

Iain Harper's analysis of production agent security emphasizes that the boundary between "helpful behavior" and "unauthorized action" is often ambiguous in agent systems, and the default should always be restrictive.

Detection:

  • Audit logs for actions that exceed the intended scope. If your "customer support" agent is calling admin APIs, you have a guardrail problem.
  • Run adversarial testing: ask the agent to do things just outside its intended scope and verify it refuses.
  • Monitor for privilege escalation patterns where the agent combines multiple low-privilege tools to achieve a high-privilege outcome.

Fix:

  • Define a strict allowlist of actions, not a blocklist. The agent can do exactly these things and nothing else.
  • Implement the principle of least privilege for tool access. If the agent only needs to read user data, don't give it write access.
  • Add a policy layer between the agent's decisions and actual execution. This layer checks every proposed action against your business rules before it runs.
  • For high-stakes domains (healthcare, finance, legal), require human approval for any action above a defined risk threshold. The overhead is worth it.

The Meta-Fix: Wrap Agents in Workflows

Here's the pattern that prevents most of these failure modes simultaneously: don't give the agent full autonomy. Instead, wrap it in a deterministic workflow.

Anthropic's own guidance on building effective agents is explicit about this: start with the simplest architecture that solves the problem. Most tasks that feel like they need an autonomous agent actually need a structured workflow with one or two LLM-powered steps.

The workflow handles routing, validation, cost caps, and guardrails. The LLM handles the parts that actually require language understanding. This separation means your failure modes are contained and observable.

A practical architecture looks like this:

Layer Responsibility Implementation
Input validation Schema checking, rate limiting Deterministic code
Routing Which task type is this? LLM classifier or rules
Execution The actual agent work LLM with tools
Output validation Does the result make sense? Deterministic checks + LLM judge
Action gating Should we execute this action? Policy engine + human approval

Every production agent we've deployed at OpenNash uses some version of this layered approach. The agent itself is responsible for the smallest possible slice of the overall system. Everything else is predictable, testable, and cheap.

The teams that ship reliable agents aren't the ones with the most sophisticated prompts. They're the ones who spent the most time on the boring stuff: eval suites, cost monitoring, tool call validation, and scope restrictions. The agent is the easy part. Keeping it from breaking is the actual engineering challenge.