10 ways AI agents
fail in production.

The agent produces confident-sounding outputs that are factually wrong. These get passed to downstream systems — databases, APIs, other agents, or customers — which act on them as if they were correct. By the time a human reviews the output, the cascading damage has already propagated.

Hallucinated outputs don't throw errors. They look exactly like correct outputs — same format, same confidence. There's nothing in your logs to indicate a problem. The only signal is semantic: the content is wrong. That requires continuous quality monitoring, not just error monitoring.

The agent enters a retry cycle on a single tool call — invoking the same function repeatedly without making progress. The session hangs. API costs accumulate. Most teams discover this failure mode when they see an unusual spike in their LLM billing, often days or weeks after the fact.

From the outside, the agent appears to be "thinking." There's no exception, no timeout warning in most frameworks. The loop continues until an external rate limit or token budget is hit. By then, the cost is already incurred.

Partway through a session, the agent loses coherence. It begins responding to things that weren't asked, ignores prior context, or gives answers that bear no relation to the current conversation state. To the user it looks like the AI "broke" — an impression that is very difficult to undo.

Context collapse doesn't produce an error code. The agent continues to respond — it just responds badly. Catching it requires understanding the expected relationship between input and output across a session, which most logging systems don't track.

A crafted user input instructs the agent to ignore its original instructions and take different actions. The agent complies — because it cannot inherently distinguish between trusted instructions and injected ones. Consequences range from data exposure to executing actions the agent was never authorized to perform.

The agent appears to be functioning normally — it's responding, completing tasks. The problem is what tasks it's completing. Without continuous monitoring of whether the agent's behavior stays within its intended scope, injections can run undetected for extended periods.

Over time — weeks, sometimes months — output quality gradually worsens. Responses become less relevant, less accurate, less useful. There's no single moment of failure. The decline is slow enough that no individual output stands out as wrong. The first signal is often a user churn metric or a support ticket that says "this used to be better."

By definition, silent degradation has no error signal. It requires comparing current output quality against a historical baseline — not just checking whether the agent is running. This is the failure mode most teams never catch without dedicated monitoring infrastructure.

Your agent is functioning correctly — but a service it depends on (a search API, a database, a third-party tool) is degraded or unavailable. Your agent can't complete its task. From your users' perspective, your product stopped working. They don't know or care that the failure is upstream.

Dependency failures are often partial: the service is slow, returning errors on some requests but not others. This produces inconsistent behavior that's easy to misattribute to the agent itself. Without monitoring external dependencies alongside agent traces, the root cause is unclear.

The agent begins taking actions that fall outside its intended authorization boundary. This can happen gradually as prompts evolve, or suddenly after a model update changes how instructions are interpreted. The result: records accessed without authorization, messages sent without approval, transactions initiated beyond the agent's intended scope.

The agent isn't returning errors — it's completing actions. Whether those actions are authorized requires comparing behavior against an expected boundary, which is only possible with continuous scope monitoring. By the time a human reviews logs manually, scope creep has already compounded.

The agent's retrieval system (vector database, conversation history, knowledge base) contains incorrect, outdated, or deliberately poisoned data. The agent retrieves this data, treats it as ground truth, and makes decisions based on a foundation that is quietly wrong. Outputs look plausible — they're just built on bad premises.

Memory poisoning is invisible at the output layer. The agent's responses may look reasonable — they're internally consistent with the corrupted memory. Catching it requires monitoring the integrity of retrieved context, not just the quality of final outputs.

In a multi-agent pipeline, Agent A is waiting on output from Agent B, Agent B is waiting on Agent C, and Agent C is waiting on Agent A. The circular dependency means no agent can proceed. The entire workflow freezes. No exception is raised. Downstream systems waiting on the pipeline's output simply time out — or wait indefinitely.

Unlike a single agent looping (AFT-02), orchestration deadlock spans multiple agents. No individual agent is misbehaving — each one is waiting correctly for its dependency. The failure is at the coordination layer. This requires monitoring the pipeline as a whole, not individual agents in isolation.

OpenAI, Anthropic, Mistral, and other LLM providers regularly update their models — sometimes with silent version increments that change output behavior without a public changelog. Your prompts were tuned for the previous model version. After the update, output parsers may break, carefully tuned behavior shifts, or instructions are interpreted differently. The API returns 200. Everything looks fine. The results are wrong.

AFT-10 is distinct from infrastructure failure (AFT-06) — the dependency is available, it's just changed. Because the change is in the model's behavior rather than your code, it won't appear in your version control, your deployment logs, or your error monitoring. Only output-layer behavioral baselining catches it. Teams typically discover AFT-10 through customer complaints, often days after the regression began.