Every agent system fails in the same handful of ways. Knowing the taxonomy in advance turns mysterious production incidents into recognizable patterns with known fixes.
The five recurring failures
1. The confident wrong turn. The agent misreads the situation early — wrong file, wrong assumption about the schema, wrong interpretation of the goal — and everything downstream is internally consistent and globally wrong. The fix is rarely better reasoning; it is earlier verification. Cheap checks at the start of a task (does this file exist? does the test currently pass?) anchor the agent to reality before it builds on a guess.
2. The loop that isn't progressing. The agent alternates between two states — apply fix A, see new error, apply fix B, see the original error — without recognizing the cycle. Detect it mechanically: if the same tool call with the same arguments appears twice, or the same error message recurs three times, break the loop and escalate. The model will not reliably notice its own cycles; the harness must.
3. Context rot. Twenty turns in, the window holds three abandoned approaches, two stale file snapshots, and the residue of every dead end. The agent starts confusing the current state with a superseded one. This is the failure that compaction (chapter 3) exists to prevent — and the reason compaction must preserve decisions and dead ends rather than raw history.
4. The over-helpful expansion. Asked to fix a bug, the agent also reformats the file, renames two variables, and adds error handling nobody requested. Each addition is locally defensible; the sum is an unreviewable diff. Constrain by instruction ("only make changes directly requested") and verify by diff size: a one-line bug report that produces a two-hundred-line diff should trip a review gate.
5. The silent skip. The agent cannot complete a step — a missing credential, a tool that errors — and instead of stopping, routes around it and reports success on the parts it could do. The report reads as a finished task. Require explicit accounting: the final report must list each subtask with its outcome, and the harness should treat "not mentioned" as "not done."
Instrument first, fix second
None of these failures can be addressed from inside the prompt alone. They are visible only in traces: tool-call sequences, error frequencies, diff sizes, token spend per task. Before tuning prompts, build the boring observability — log every tool call with its arguments and result, every loop iteration, every stop reason. The teams that skip instrumentation end up tuning prompts against anecdotes, which is how a fix for one failure quietly causes another.