An agent that crashes is the easy case. You get a stack trace and a place to start.

The hard case is the agent that finishes. It ran for three hours, completed every step, returned a confident answer, but the answer was wrong, for a reason that started two hundred steps earlier and never raised an error.

This is a reference for those failures: what each one is, why it happens, and where it becomes visible.

Why agents fail differently

A traditional service fails where it breaks. The point of failure and the point of cause are usually the same place.

Agents break that. An agent is a sequence of decisions, each conditioned on the output of the last. A malformed argument at step 2 returns plausible data. The agent builds on it. Step 40 produces a wrong result and looks perfectly reasonable in isolation.

Three consequences run through every mode below:

• The crash point isn't the cause. What you need is the first divergence.

• Individual steps look fine. Inspecting one LLM call rarely reveals the problem.

• Most agent failures are silent. No error code, no alert, no failed status.

A shared taxonomy of these failures is converging across the industry and others have published similar versions. This page follows that consensus, splits frozen agents out from retry loops as a distinct mode, and organizes the set by when each becomes detectable.

1. Tool misuse

Tool misuse is when an agent calls the wrong tool, passes invalid arguments, or proceeds as though a failed tool call succeeded. It's the most common agent-specific failure in production and the most damaging, because a bad value early corrupts every step built on it.

Why it happens. This issue comes from loose schema interpretation by the model, unvalidated data transfers between pipeline steps, and tools that fail silently instead of throwing explicit errors.

The worst variant: the silent empty response. A tool returns HTTP 200 with an empty array, a default value, or truncated data. Nothing failed. The agent reads "no data" as "no such data exists" and continues on a false premise. This single pattern accounts for a large share of confidently wrong outputs.

Where it's visible. At the call: argument schema violations, tools invoked outside their normal distribution, responses that are technically successful but empty.

2. Context loss

Context loss is when an agent stops honouring constraints, facts, or instructions established earlier in a run. The agent hasn't malfunctioned; the information simply isn't in front of it anymore.

Why it happens. Context window pressure pushes early instructions out as the run grows. Retrieval or memory layers fail to surface what matters. Recent context gets over-weighted against earlier input.

What it looks like. A research agent told "only peer-reviewed sources after 2023" returns a blog post at turn 15. Nothing failed. The constraint left the window.

Where it's visible. Mid-run, if you check whether declared constraints still appear in the active context and it's undetectable if nothing recorded the constraints in the first place.

3. Goal drift

Goal drift is when an agent gradually stops working toward its original objective while continuing to behave coherently at every step. No step fails. The cumulative effect of small deviations produces output that doesn't serve what was asked.

Why it happens. Objectives held only in conversational context rather than tracked explicitly; one sub-goal expands to crowd out others, and restarts reload a state that has already lost the goal.

What it looks like. An agent asked to review code for security issues and performance spends its remaining context on performance and never returns to security. Users describe it as the agent "forgetting."

Where it's visible. Mid-run, by checking whether every declared objective still appears in the agent's active plan.

4. Retry loops

A retry loop is when an agent repeats the same action without changing strategy, usually after a failure it can't interpret. Loops are expensive by nature: token and latency cost compound with every iteration, and many only end when a timeout kills the run.

Why it happens. No backoff or circuit breaker on tool wrappers, no escalation path after N attempts, and no logic distinguishing "retry might help" from "retry cannot help."

What it looks like. A tool returns a timeout. The agent retries identically. Same timeout. Forty times, metering all the way.

Where it's visible. Within seconds: the same tool called with the same arguments above a threshold. One of the cheapest signals to implement and among the most valuable.

5. Frozen agents and reasoning stalls

A frozen agent is one that has stopped making progress without crashing, erroring, or completing. It hasn't failed in any way a monitoring system recognizes. It simply stopped.

Why it happens. Waiting on a dependency that never answers, cycling between two sub-goals that each depend on the other, or a reasoning state with no exit condition.

Why it's uniquely dangerous. Every other mode eventually produces output you can inspect. This one produces nothing. And in any system that reports on completed runs, a frozen agent is indistinguishable from a slow, healthy one, indefinitely.

Where it's visible. Only while the run is live, via a progress heartbeat. There is no post-hoc detection for this mode, because there's no post.

Learn how Rius works and observes Live Agents here.

6. Cascading failures in multi-agent systems

A cascading failure is when one agent's bad output becomes another agent's trusted input, propagating the fault across agent boundaries. The receiving agent has no way to know its input is corrupted, so it produces a second-order failure that's even harder to trace back.

Why it happens. No validation at agent boundaries, outputs treated as authoritative because they came from a sibling agent, and state desync where two agents hold inconsistent views of shared truth.

What it looks like. A retrieval agent returns partial results. A synthesis agent treats them as complete. A reporting agent publishes the conclusion. Three agents, one root cause, and the visible failure is furthest from the source.

Where it's visible. At the boundary: a child run that failed or returned invalid output while the parent proceeded regardless.

7. Silent quality degradation

Silent quality degradation is a gradual decline in output quality with no discrete failure event. No error, no alert, no single bad run. Just a slow slide that's obvious in hindsight and invisible in the moment.

Why it happens. Model version changes, prompt drift, shifts in the distribution of incoming requests, and accumulated small changes that individually look harmless.

Where it's visible. Only across many runs, through quality-score trends over time. This is the one mode that genuinely can't be caught within a single run and it's completely invisible to error-rate monitoring.

The seven modes at a glance

Six of seven produce no reliable error. Six of seven are detectable while the run is still live. That gap, i.e., the time between what error monitoring sees and what's actually known in the moment, is the whole problem.

So how do you detect them?

Every mode above leaves a signal. Most of those signals fire before the run ends.

Building the system that watches for them (from instrumentation, baselines, to alert on, and  all the way to what to do when one fires) is a subject in itself. See these failures as they happen

GlassFlow Rius captures every step as it happens, holds a run together as one session across restarts and sub-agents, and flags agents that stop making progress so the six silent modes stop being silent.

FAQ

What are the main AI agent failure modes?
Seven: tool misuse (including silent empty responses), context loss, goal drift, retry loops, frozen agents and reasoning stalls, cascading failures in multi-agent systems, and silent quality degradation. Six of the seven produce no error code.

What's the most common AI agent failure mode?
Tool-related failures: wrong tool, invalid arguments, or a call that returns successfully with no usable data. They're also the most damaging, because a bad value at an early step silently corrupts everything built on it.

Why don't agent failures show up as errors?
Because agents are designed to keep going. A tool returning empty data, a constraint falling out of context, or an objective quietly dropped are all states the agent can proceed from. Nothing raises an exception, so error-rate monitoring sees a healthy run.

How are agent failures different from LLM failures?
LLM failures (hallucination, refusal, low-quality output) are visible in a single response. Agent failures emerge from the interaction between steps: a bad output at step 3 corrupting step 40.

Which failure modes can you catch while the agent is still running?
All except silent quality degradation, which only appears across many runs. Tool misuse, retry loops, and frozen agents are detectable within seconds; context loss and goal drift with periodic checks; cascading errors at the agent boundary.

What is a frozen agent?
An agent that has stopped making progress without crashing, erroring, or completing. It produces no output to inspect and no closed trace, so it's indistinguishable from a slow healthy run in any tool that reports only on finished runs. A progress heartbeat is the only reliable detection.