AI Agent Failure Modes: 9 We Hit in Production

Why do AI agent failure modes keep reaching production?

Most agent demos never ship because they test the happy path once, while production tests every unhappy path continuously. The result is a catalogue of repeatable AI agent failure modes, and most of them respond to ordinary engineering discipline.

Viithiisys builds software for clients, and the agent work we do now fails in the same places older integration work did: at the boundaries, under load, and when nobody is watching.

What follows are nine failure modes we have met in production agents. For each we describe the symptom, what happened, and the fix. A guardrail checklist at the end maps every mode to the control that contains it.

What counts as an AI agent failure mode?

An agent failure is any run where the system completes, or appears to complete, without achieving the intended outcome safely. A crash is the easy case, because someone notices. The expensive ones return a confident answer built on a failed step.

A failure mode is a repeatable pattern behind those runs. Once you can name the pattern, you can add a control for it and test that the control holds.

1. Why does a silent tool failure go unnoticed?

Symptom: A tool call returns an error, an empty list or a truncated payload, and the agent treats it as a valid result. The run finishes, the answer looks plausible, and nobody learns anything went wrong.

In one of our production agents, a search tool returned an empty array when upstream authentication expired. The model read "no results" as a finding and told the user nothing matched. Because nothing errored, the problem only surfaced when a user questioned an answer, and we had no log line to search for.

Fix: Make failure loud.

• Every tool wrapper returns a typed result with an explicit status, never a bare empty value.
• Schema validation runs on every response.
• An empty result from a tool that should rarely be empty raises a flag.

Anthropic's guidance on building effective agents makes the same point: agents get ground truth from the environment at each step, so that signal must be trustworthy.

2. Context drift over long runs

Symptom: Context drift is the gradual loss of the original goal, constraints or earlier facts as a run accumulates tool output and intermediate reasoning. The agent keeps working, but on a slightly different task.

Research on long contexts shows models use information in the middle of a long input less reliably than information at the start or end, as reported in Lost in the Middle. We saw the practical version: a multi-step workflow that forgot a user's exclusion rule partway through and then proposed exactly the items the user had ruled out.

Fix: Our fixes are structural.

• Restate the task and hard constraints at fixed intervals.
• Summarise and prune tool output instead of appending it.
• Move durable state into an external store the agent re-reads.
• Split long runs into short sub-runs with a checkpoint between them.

3. Retry storms and cost blowouts

Symptom: An agent that retries on failure without a limit can loop thousands of times against a broken dependency. Cost, rate limits and downstream load all grow together, usually overnight.

Our incident here was a tool that returned a recoverable-looking error. The model dutifully tried again, with slight variations, for hours. The bill was the first alert we got, which tells you how little visibility the run had.

Fix: The fix has three layers.

• A hard cap on steps and tokens per run, enforced in code.
• Retries with exponential backoff and jitter, following the pattern in the AWS Builders' Library.
• A circuit breaker that stops the agent calling a dependency that has failed repeatedly, and escalates to a human instead of improvising.

4. Unbounded tool access

Symptom: Giving an agent every tool "so it can be flexible" means a single bad inference can reach production data, send email or delete records. The blast radius of a mistake equals the permissions you granted.

We reviewed one early agent and found it held write access to systems its task never touched, because the shared service account was convenient. Nothing went wrong, which is the only reason it was a finding and not an incident. The audit removed every scope the task did not need.

Fix: Apply least privilege per task, not per agent.

• Read-only is the default.
• Destructive or external actions need a separate scoped credential.
• Above a threshold, a human approves the action.

The Anthropic tool use documentation is clear that your code executes the tools, so your code is where the policy belongs.

5. How does eval rot let quality slip unseen?

Symptom: Eval rot is when your test set stops representing real traffic. The agent scores well on the benchmark while real users hit cases nobody wrote a test for, and quality slips without any alarm.

We shipped an agent with a good evaluation score, then watched usage shift toward a request type that made up almost none of the original set. Once we measured that slice separately, it performed clearly worse than the headline score implied, and the headline number had been hiding it.

Fix: Treat the eval set as a living asset.

• Sample real production runs weekly and label the failures.
• Add those failures as permanent regression cases.
• Run the full set before every prompt or model change is released.

Teams that already practise software testing and QA will recognise this loop; the agent version only changes where the test cases come from.

6. Hallucinated IDs in write operations

Symptom: Models invent plausible identifiers: an order number, a customer ID, a SKU. In a read operation this yields a not-found error. In a write operation it can update the wrong record, or create a phantom one.

The worst variant is an ID that exists but belongs to someone else. We saw this class of error in a workflow that updated records by reference, and the audit afterwards had to check every write the agent had made, not just the ones that looked suspicious.

Fix: Never let the model originate an identifier.

• IDs come from a prior tool result or a lookup.
• The write tool validates that the ID was returned earlier in the same run.
• High-impact writes add a read-back step: fetch the target, show the diff, then commit.

If you are building agents that write to transactional systems, our AI agent development work applies these checks from the first design review.

7. Latency compounding

Symptom: Each step in an agent loop adds model time plus tool time. Five sequential steps at a few seconds each turn a snappy prototype into a workflow users abandon.

On one customer-facing agent, most of the end-to-end delay sat in sequential calls that did not depend on each other. Nothing was slow on its own; the total was slow because the steps queued behind one another.

Fix: The fixes are mostly familiar.

• Run independent tool calls in parallel.
• Use a smaller, faster model for routing and extraction, and reserve the large model for the step that needs it.
• Cache stable lookups.
• Stream partial progress to the user so waiting feels shorter.

Finally, set a timeout per step and a total budget, so a slow dependency degrades gracefully instead of stalling the whole run.

8. No rollback path

Symptom: When an agent writes to real systems, some of those writes will be wrong. Without a way to undo them, every error becomes a manual clean-up exercise.

Early on, we had an agent making batches of changes with no record of what it had changed. Reconstructing the original state meant engineers comparing backups against live data by hand, which took far longer than building the log would have.

Fix: Design for reversibility before the agent ships.

• Log every write with the prior value and a run ID.
• Stage and commit actions where possible, instead of applying them immediately.
• Give batches a dry-run mode, and add a kill switch that stops a run mid-flight.

Anything that cannot be reversed, such as sending an email, goes behind an approval gate.

9. Nobody owns the prompt

Symptom: The prompt is production code, but it is often edited in a dashboard by whoever last touched it. Behaviour changes with no diff, no review and no way to find out which edit broke what.

We traced one regression to a small wording change made in good faith weeks earlier. With no history to compare, finding the offending edit meant replaying old conversations until the behaviour changed.

Fix: The fix is organisational.

• Prompts live in version control, change through pull requests, and run against the eval set in CI.
• Each prompt has a named owner who is accountable for its behaviour.
• Model upgrades are treated as releases with a rollout plan, not silent swaps.

This is the unglamorous side of MLOps, and it decides whether an agent stays good after launch.

Which guardrails contain these AI agent failure modes?

Agent guardrails are enforced limits on what an agent can read, call, write and spend. They live in code, not in the prompt, and each maps to one of the nine failures above.

• Silent tool failure: typed results and schema validation, enforced in the tool wrapper.
• Context drift: periodic task restatement and external state, enforced in the orchestrator.
• Retry storms: step and token caps, backoff and a circuit breaker, enforced in the orchestrator.
• Unbounded tool access: per-task least privilege and approval gates, enforced in the credential layer.
• Eval rot: weekly production sampling into a regression set, enforced in CI and monitoring.
• Hallucinated IDs: IDs only from prior tool results, plus read-back, enforced in the write tools.
• Latency compounding: parallel calls, step timeouts and model routing, enforced in the orchestrator.
• No rollback path: prior-value logging, dry run and a kill switch, enforced in the data layer.
• Unowned prompt: version control, a named owner and CI evals, enforced in the repository.

How do you start if you already have an agent running?

Start with logging and caps, because they are cheap and expose everything else. Then audit permissions, then add the read-back to any write path. Last, build the eval set from real runs so the controls stay honest after launch.

If you are unsure which of these nine your agent is exposed to, a broken workflow assessment is the quickest way to find out. We walk through the agent's tools, permissions and write paths against this list and tell you where to begin. If you would rather talk through a specific agent first, use the contact form.