The Failure Catalog: 22 Ways Every Agent Fails, and the Prompts That Guard Against Them
Every agent you build fails in the same ways. Not similar ways. The same ways.
I have watched enough agents break, in production and in demos, to stop treating each failure as a surprise. The surprises repeat. A coding agent claims it ran a test it never ran. A research agent answers the question it recognizes instead of the one you asked. A long-running agent forgets the instruction you gave it forty turns ago. These are not bugs in your prompt. They are properties of the tool, and they show up whether you are building on the newest frontier model or last year’s.
So I cataloged them. Twenty-two failure modes, each with the drop-in prompt that guards against it. This is the field guide I wanted when I started and could not find, because most writing on this treats each failure as novel. It is not novel. It is a pattern, and patterns can be named, grouped, and defended against.
Why prompt for the failure, not the task
Most prompt advice optimizes the happy path. Write a clear instruction, give good examples, specify the format. That work matters, and it is not what this is about.
This is about the unhappy path. The failure modes fire precisely when your careful instruction was not enough, and they fire silently. The agent that fabricates a citation does it with the same fluency as a real one. The agent that pads a thin answer with confident headers looks more finished, not less. You do not catch these by writing a better task description. You catch them by writing guards aimed at the specific ways the model goes wrong.
So, stop asking, “how do I describe what I want.” Start asking “how does this tool fail, and what instruction closes that gap.” The task prompt gets you the output. The failure prompt gets you validation of the output.
The four groups
The twenty-two sort into four families by where they strike.
Reasoning failures. The model solves the wrong problem or accepts a broken premise. It substitutes the familiar version of your question for the actual one. It builds on a false assumption in your prompt instead of challenging it. It commits to the first plausible answer and never generates a second. These fail before a single line of output is wrong, in the reasoning that produced it.
Instruction failures. Your instructions decay. Early constraints lose force as context grows. Prohibitions fade faster than positive instructions, because “do not do X” is a weaker signal than a pattern for doing X. Ambiguity gets filled with a silent guess instead of a question. The agent widens a narrow task because more output reads as more help.
Output integrity failures. The model produces the shape of finished work without the substance. A stub presented as a complete function. A claim of testing with no test run. Confident structure wrapped around thin content. Agreement with your pushback even when you were wrong.
Agentic execution failures. These belong to agents specifically, the ones with tools and autonomy. The agent follows instructions buried in a web page it read, because it cannot tell your commands from the data it is processing. It edits the test to pass instead of fixing the code. It overwrites a file without reading it first. It loses the constraint stated in the middle of a long document, where attention runs thinnest.
How to use it
Do not load all twenty-two into every agent. That recreates the problem the catalog is trying to solve; twenty-two guards competing for attention is its own kind of dilution.
Instead, match the guards to the work. Four are universal and belong in every agent: the ones covering fabrication, overconfidence, silent assumptions, and sycophancy. These fail in every kind of task. The rest go into leaf files loaded by role. A coding agent gets the coding set. A research agent gets the reasoning set. An agent that reads external data gets the prompt-injection guard, non-negotiably.
And the whole thing collapses into four checkpoints an agent can carry without the full catalog in context. Before answering, check the premise. On ambiguity, state the assumption. Before claiming done, verify and report what you did not check. On push-back, re-evaluate on the merits rather than folding. Most of the twenty-two are covered by those four moments.
The honest part
Not every prompt in the catalog fixes the failure it targets. Most reduce it. A few can only flag it.
Three failures are architectural, or trained-in, at a level no instruction reaches. Sycophancy is rewarded by the training process itself; a prompt buys resistance, but the pull reasserts under pressure. Prompt injection exploits the model’s inability to separate instructions from data, a gap that needs system-level controls, not just a well-worded instruction. Overconfidence has no native calibration signal to correct. For these, the honest label is “guard,” not “fix,” and every card in the catalog says which it is.
I would rather ship a catalog that tells you where its own prompts fall short than one that pretends twenty-two instructions solve twenty-two problems. The first is a tool you can trust. The second is the exact kind of confident, unverified output the catalog exists to catch.
Twenty-two failure modes. Four groups. Four checkpoints. A prompt for each, and an honest label on every one.
The tool fails in known ways. Guard the known ways.
The interactive catalog lives here, filterable by the kind of work you do, with a copy button on every prompt: robertrevans.com/specs/failure-modes
The map underneath it: the twenty-two are not twenty-two problems. They trace to five root mechanisms. Read the taxonomy →
More of the work: robertrevans.com