AI Agent Failure Modes: A Taxonomy for Business Agent Reliability

A business AI agent usually fails in a small number of recognizable ways: its memory is out of date, it retrieves the wrong context, it picks the wrong tool, it repeats an action it already took, or it keeps working when it should stop. Naming these failure modes before an incident lets an operations team identify which layer broke and who should fix it. This guide lists the common types, explains how each one looks from the outside, and gives a method for diagnosing them.

Key takeaways

• Most agent failures fall into five layers: memory, context, actions, process and handoff.
• Name the failure type before you change the prompt, the model or the tools.
• Stale memory and wrong tool choice can look identical in a reply but need different fixes.
• Every action that changes a record or sends a message needs a stated rule for duplicates and permissions.
• Each failure type needs an owner, a check and a review cadence, or it will be rediscovered every quarter.

Why name failures before you fix them

When an agent gives a wrong answer, the usual reaction is to rewrite its instructions. That sometimes helps, but it hides the cause. A outdated service note in memory, a search that missed the right policy page and a tool call with the wrong customer identifier can all produce the same visible symptom: a confident, wrong reply. Each one needs a different owner and a different test.

A shared vocabulary turns a vague complaint, such as "the agent is unreliable," into a diagnosis that a manager can act on. It also makes incident notes comparable over time. If three of the last five problems were stale memory, the fix is probably a memory review process, not a better model.

The taxonomy below is organized by where a failure starts. It is not a ranking, and the categories overlap in practice. An agent can misread a document, save the misreading as memory, and then act on it. Trace the earliest broken layer first, because downstream symptoms often hide it.

Memory failures: stale, contradictory and missing

• Stale memory: a fact was true when it was stored and is no longer true, such as a delivery area, a supplier name or a price rule version.
• Contradictory memory: two saved notes disagree, and the agent picks one without saying that a conflict exists.
• Missing memory: a fact that staff know was never recorded, so the agent asks again, guesses or leaves the answer blank.

Memory failures are hard to spot because the answer sounds right. Check where each fact came from, when it was written and who approved it. Corrections made by staff should pass through a review step before they become durable memory, since a single unreviewed correction can quietly override a correct rule. The practical method is described in Turning Staff Corrections Into Reviewed Memory for AI Agents.

Context and input failures

• Retrieval miss: the right document exists, but the search returned a different passage or none at all.
• Misread input: the agent parsed a scanned table, a footnote, a date format or a currency field incorrectly.
• Injected instruction: text inside an email, a web page or a shared document tries to change what the agent does.

Retrieval misses are the most common context failure and the easiest to test. Log the passages the agent actually received, not only the final answer. If the right passage was never in the context window, no prompt change will fix the reply. Input misreads need a different check: compare the agent's extraction with a human-verified sample of the same documents.

Injected instructions deserve their own category because the attacker or the careless sender does not need access to the agent. The OWASP guidance on LLM risks treats untrusted content as data, not as commands, and that separation should be designed into the workflow. Keep instructions from the owner in one channel and content from third parties in another, and never let a document decide which tools are allowed.

Illustrative scenario: A small property management team uses an agent to draft replies to maintenance requests. A tenant's message includes a line asking the agent to ignore the approval step and mark the request as closed. The reply draft changes its tone, but the close action is blocked because the agent's tool permissions do not include closing requests without a staff member's confirmation. The incident is logged under injected instruction, and the team reviews whether the message filter needs a rule.

Action failures: wrong tool, wrong arguments, duplicates and overreach

• Wrong tool choice: the agent searches a knowledge base when the question needs the booking system, or it calls a write tool to answer a read-only question.
• Wrong arguments: the tool is right, but the customer, amount, date or record identifier is wrong.
• Duplicate effect: a timeout led to a retry, and the original action had already succeeded, so the change ran twice.
• Permission overreach: the agent could perform an action that the task never required.

Wrong tool choice often comes from unclear tool descriptions. When two tools overlap, the model has to guess, and the guess is only as good as the description. Write each tool description as a rule: what it does, when to use it, and when not to. Anthropic's guidance on writing tools for agents makes the same point from the engineering side.

Duplicate effects are a design problem, not a model problem. Any action that creates a payment, sends a message or changes a record needs a stable key so that a retry cannot create a second effect. The approach is covered in Idempotent AI Agent Actions: How to Prevent Double Refunds. Permission overreach is best handled at the start, by giving the agent the smallest access that the role requires, as explained in Least privilege for AI agents: start with the smallest access.

Process failures: loops, silent partial work and drift

• Loop: the agent repeats the same search or message without progress, and no stop condition ends the run.
• Silent partial completion: the agent reports that a task is done when one of several steps failed or was skipped.
• Drift: quality declines slowly after a model update, a change in documents or a shift in how customers write their requests.

Silent partial completion is the failure that most damages trust, because the summary is wrong and the log looks clean. Require the agent to report each step's result separately, and make the task close only when every required step reports success. Loops are easier to contain with explicit stop conditions, such as a maximum number of tool calls and a rule that sends the case to a person after repeated failures.

Drift is slow and therefore easy to miss. A monthly sample of outputs, scored against the same criteria, will show a decline long before customers complain. The signs are described in AI Agent Drift: How to Spot Quality Decline Over Time. Structured logs for each step, following common observability practice such as the concepts in the OpenTelemetry documentation, make these failures visible without reading every conversation.

A five-step method for diagnosing a failure

When a failure is reported, the first goal is to classify it, not to fix it. A simple method works for most teams:

• Step 1: Reproduce the case with the exact input, date and record state, and save it as a test case.
• Step 2: Read the trace in order: memory used, passages retrieved, tools called, arguments sent, results returned.
• Step 3: Find the earliest step that was wrong, and assign it to one of the categories above.
• Step 4: Choose the narrowest fix for that layer, such as correcting one memory entry, rewriting one tool description or adding one stop condition.
• Step 5: Rerun the saved case and a small set of related cases, then record the failure type and the fix in the change log.

The last step matters most for the long term. A team that records failure types for a quarter can see which category keeps returning, and that pattern points to the layer that needs redesign. Keeping the record readable for non-engineers is also useful, which is why Superintelligent Agents Need a Change Log Owners Can Read is a useful companion.

How Be Human handles these failures in managed operations

Be Human designs each agent with a defined role, its memory sources, its tool permissions and its approval boundaries before it goes live. In managed operations, the same taxonomy is used to label every incident, so that monitoring, permission reviews and recurring evaluations report by failure type rather than by a general sense of quality. Changes to memory, tools or instructions are logged with an owner and a reason, and incidents follow a written response path with a rollback option. Ongoing work covers integration maintenance and controlled improvements, so the failure types that recur are addressed at their source.

If you want to find the first task worth handing to an agent, take the free Be Human AI diagnostic.

Frequently asked questions

What is the most common cause of an AI agent failure? There is no single cause, and the most common failures differ by workflow. Stale memory and retrieval misses often appear first in business agents because the information changes and the search is imperfect. Trace logs are the only reliable way to know which layer broke in a given case.

How do I tell a memory failure from a tool failure? Look at what the agent knew and what it did. If the tool received the correct arguments and returned the correct result, but the agent used an outdated fact to decide what to ask for, the problem is memory. If the facts were correct but the tool call used the wrong identifier or the wrong tool, the problem sits in the action layer.

Should I fix every failure by rewriting the prompt? No. A prompt change can hide a memory or permission problem for a few weeks and then fail again in a new form. Use the prompt for instructions that belong to the role, and fix the underlying layer when the failure type points to memory, retrieval, tools or permissions.

Can a small company manage these failure types without an IT team? Yes, if the owner can read a simple log and approve changes to memory, tools and permissions. The work is mostly review and classification, and the technical changes can be handled by a managed operations partner. Start with one workflow, one owner and a short list of failure types, then expand once the review habit is established.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.