AI Agents Keep Making the Same Mistakes? Try Looking for Common Ground

In the Sherlock Holmes stories, Moriarty never appears at the crime scene. Holmes catches him because the seemingly unrelated cases all fit the same pattern. The same might be true of AI agent failures.

A Worrying Pattern: Fixing Bugs One at a Time

A developer on Reddit proposed this analogy and shared their paper. They observed that agent failures are usually handled like this: a fabricated ID, a step marked "complete" that was never actually executed, an instruction explicitly ignored—and then we fix them one by one.

This "whack-a-mole" approach to fixing is the norm in agent development today. Each time a specific failure case appears, the developer writes a patch for it, adds a rule, or tweaks a prompt. The problem seems solved in the short term, but the next failure soon pops up—and it often looks quite different.

The developer's core hypothesis is that these superficially different failures may stem from the same underlying problem.

The Common Pattern: Treating "Unchecked" as "Checked"

The hypothesis is very specific: what many agent failures have in common is that the agent treats something it never actually verified as already checked.

This description pinpoints a key fragile link in agent design—self-verification. When an agent is responsible for judging whether its own output is compliant, whether a step is complete, or whether an ID is valid, it is effectively using its own reasoning ability to vouch for its own reasoning. Once this link goes wrong, failures manifest in various forms:

• Fabricating a plausible-looking ID because it "thinks" it's correct
• Marking an unexecuted step as complete because it "feels" it should have been done
• Ignoring explicit instructions because it "believes" it followed them

From the outside, these are completely different types of errors; but from the inside mechanism, they all point to the same failure point: the verification step was skipped, or performed incorrectly.

It's worth noting that the "Moriarty" in this analogy does not involve any conspiracy or intent. It is purely a structural metaphor—there is a common trigger behind multiple independent failures.

Self-Verification in the context of AI agents refers to the agent using its own reasoning ability to assess the correctness of its output, the completeness of steps, or the validity of tool calls. This contrasts with the idea of "independent verification" in traditional software testing: test cases are written externally and assertions are executed by code not involved in the implementation, thus avoiding the logical loop of "proving yourself correct." In LLM-based agents, self-verification typically takes the form of having the model review its own output and judge compliance, but the model's confidence in its own output tends to be high, making it easy to mistake "looks plausible" for "already verified"—which is precisely one of the common triggers of the failures described in this article.

The Limits of Fixing One by One: Why Patches Can't Stop the Next Failure

If a unified pattern truly exists, then fixing individual failures one by one has a fundamental limitation.

Each case you fix addresses the surface symptom of that case, not the mechanism that produces the symptom. The next failure may appear in a completely different functional module, a different task type, or a different model call path, but it may still stem from the same vulnerability of "unchecked treated as checked."

This explains why many agent systems still fail in unpredictable ways after extensive iteration and patching. The more developers fix, the thicker the patches, but the system's behavior doesn't necessarily become more reliable—because the root cause remains untouched.

The Way Forward: Build Checks into the System

The developer's suggestion in the paper is: build the checking mechanism into the system level, rather than leaving it to the agent to complete on its own.

This is a directional shift. Instead of letting the agent judge at runtime whether "this step is done" or "this ID is real," it's better to design independent verification layers or constraint mechanisms in the system architecture, making checks an unavoidable fixed part of the process.

This approach is not unfamiliar in engineering. Databases use constraints and foreign keys to ensure data integrity rather than relying on the application layer to "remember to check" every time; compilers use type systems to catch a batch of errors before runtime rather than expecting programmers to never make mistakes. Agent systems similarly need such structural safeguards.

Of course, how to do it specifically—whether with rule engines, independent verification agents, formal constraints, or runtime monitoring—is not elaborated in the original, and this itself is an open question.

Independent Verification Layer is a system architecture pattern: separating "checking" from the agent's reasoning loop and delegating it to external components that do not depend on the same model context. Common implementations include rule-based validators (such as ID formats, state machine legality), deterministic checks calling external tools (such as actually querying a database to confirm a record exists), and a "reviewer" role played by another agent. The key is that verification logic and generation logic are independent of each other, so the agent cannot bypass checks by "believing itself correct," thereby turning the structural vulnerability described in the article into an unavoidable fixed checkpoint in the process.

A Practical Question for Agent Developers

The original article ends by posing a direct question to developers: When you fix a failure, do you only fix that case, or do you look for what it has in common with other failures?

This question deserves serious consideration from anyone building agent systems. It doesn't ask you to immediately overturn your existing fix process, but suggests asking one more question after each fix: could this failure and those I've seen before be different manifestations of the same cause?

The author also explicitly states that this is an idea, not a proof. The paper is freely available, and he welcomes developers to test whether the hypothesis holds in their own systems. For agent engineering practice, this shift from "eliminating one by one" to "finding commonalities and defending systematically" may have more long-term value than any single patch.

Root Cause Analysis and Failure Mode Classification are common methods in software reliability engineering, emphasizing that after fixing a single defect, one should ask "why does this class of problem arise" and classify similar failures into unified failure modes. For agent systems, this means building a failure case library, labeling the failure point behind each failure (such as missing verification, state misjudgment, instruction drift), and then designing systematic defenses accordingly. Compared with patching case by case, the value of this approach lies in distilling scattered fix experience into reusable architectural constraints, making the system's reliability improve monotonically with iteration rather than fluctuating repeatedly.

One-line Summary

Agent failures may stem from the same pattern: treating unchecked as checked; systematic defense is needed.

Paragraph Summary

Using the analogy of Sherlock Holmes and Moriarty, the article points out that the superficially different failures of AI agents may stem from the same underlying pattern: treating something never actually verified as already checked. Developers habitually fix specific cases one by one—fabricated IDs, falsely completed steps, ignored instructions—but patches only address surface symptoms, leaving the root cause untouched, and the system still fails unpredictably. The author suggests building checking mechanisms into the system level, using independent verification layers or constraint mechanisms to make checks an unavoidable part of the process rather than relying on agent self-verification. Finally, it asks developers: when fixing failures, have you looked for commonalities among them? This view comes from a public paper and is a hypothesis, not a proof.