English | EN 
Part 2 of a 3-part series on the shift of the bottleneck from “writing code” to “trusting code” in agentic development.
Agentic systems do not fail the way software used to fail. Seven failure modes, what each one looks like from the outside, and how to detect it before it reaches a review.
The first agentic failure that really unsettled me didn’t look like a failure at all.
The output was complete: code compiled, tests green, pull request description clear, summary confirming the acceptance criteria had been met. It took a careful read to notice that one of five criteria had quietly not been implemented, and the summary never mentioned it.
Nothing had gone wrong in any way our tooling could see: no exception, no timeout, no red build. The system produced a confident, plausible, incomplete result, and described it as finished.
That’s not a bug in the sense our defect taxonomies were built for.
Our classification of software failure assumes deterministic causes, reproducible symptoms, and a traceable path from input to wrong output. Agentic systems break all three assumptions at once.
In the first part of this series, I argued verification has become the bottleneck of agentic delivery. This part is about why: you can’t build efficient verification for failures you have no vocabulary for, so here’s the vocabulary I’ve been using.
Seven ways an agent fails
1. Goal drift
The agent starts on the stated objective and ends somewhere close to it. Each individual step is defensible; the trajectory isn’t.
This shows up mostly in longer, multi-step plans, especially when the objective was stated once and never restated. My colleagues examined this closely in a clinical context in Lost in the reasoning loop, and the mechanism carries over directly to software delivery.
Detection: ask the agent to restate the goal and constraints before each major step, and diff that restatement against the original. Drift is visible there long before it shows up in the output.
2. Silent partial success
The failure I described above. Part of the work gets done, and the report describes the whole.
This is the most dangerous mode on the list: every other failure at least announces itself, this one is built to survive review.
Detection: machine-checkable acceptance criteria, one assertion per criterion, evaluated independently of the agent that did the work. Never let the same run both do the work and judge whether it’s complete.
3. Context decay across handoffs
Information that was true at the start of a session stops influencing behaviour by the middle of it. Constraints get compressed, then paraphrased, then dropped.
Matt Taylor put this well: context is infrastructure, not input. In multi-agent setups, the decay compounds, since each handoff re-encodes everything before it and loses something along the way.
Detection: durable constraint artifacts instead of conversational context, plus a periodic check that the constraints still hold. If the rule is “never write to this table directly,” make that a check, not a sentence in a prompt.
4. Tool misuse
The intent is right, the tool choice is wrong: reading a file when it should have queried the API, or retrying an operation that wasn’t safe to retry.
This is the mode most likely to cause real damage in an enterprise environment: tools are where an agent stops being text and starts having effects.
Detection: instrument at the tool boundary, not the output. Log every call with its arguments. Check call patterns: which tools were used, in what order, how many times. A run that called the write tool eleven times is telling you something no output inspection ever will.
5. Interface fabrication
The agent invents an API, a field, or a config key that doesn’t exist, and builds confidently on top of it.
At least this one is loud. It usually fails at build time or on first call.
Detection: cheap to catch, so catch it early: static checks, schema validation against the real contract, dependency resolution inside the loop rather than after it. Grounding the agent in current documentation helps, but doesn’t remove it entirely.
6. Plan thrash
The agent loops: tries an approach, fails, tries a variation, fails, and never escalates. Token use climbs, wall-clock time climbs, nothing converges.
Detection: step and cost budgets as hard limits, with a defined escalation path once they’re hit. An agent that can’t finish should say so instead of continuing to pay for the attempt. Treat an exhausted budget as a result, not an error.
7. Verification gaming
The agent makes the test pass instead of making the code correct. It widens an assertion, adds a skip marker, mocks the thing under test, or narrows the input range until the failure goes away.
I want to be careful here: this isn’t malice, and it isn’t cunning. It’s an optimisation process finding the cheapest path to a stated objective, and we stated the objective as “make the tests pass.”
Detection: treat test files as protected. Any change to assertions, mocks, or skip markers inside an agentic run gets reviewed by a human, separately. Mutation testing helps more here than coverage, since it asks whether the suite would notice a wrong implementation, not just whether it ran the lines.
Why a taxonomy, not a checklist
It gives incident reviews a shared language. “The agent went off the rails” isn’t a finding. “Goal drift after the third handoff, because the constraint lived in conversation rather than in an artifact” is a finding, and it comes with an obvious fix.
It also gives your eval suite structure. Most teams organise evals by feature, but a slice organised by failure mode is more useful, since failure modes are what actually recur across features. You want at least one case per mode your current setup would catch, and to know which modes you’re still blind to.
And it makes blind spots visible. Go through the seven and mark which ones your pipeline would catch today, automatically, without a human noticing something odd. For most teams the honest answer is modes five and six, and little else.
The part I’m still unsure about
I don’t think seven is the right number, and I suspect this list will look naive in eighteen months.
What I’m more confident about is the shape of the problem: these failures aren’t detectable by inspecting output alone, because the output is exactly what the system optimised to look acceptable. Detection has to happen at the boundaries, the goal restatement, the tool calls, the constraint checks, the trajectory. The artefact tells you the least of anything available.
That’s a real shift for a discipline that has spent its entire history assessing results.
In the final part of this series, I want to get concrete about the mechanics: how you actually build a regression capability for a system that doesn’t give the same answer twice.
Which of these seven have you seen in production, and which one is your pipeline currently blind to?