The Three Ways AI Agents Fail (and How to Fix Yours)

MIT studied enterprise GenAI adoption in 2025 and found that 95% of initiatives deliver no measurable return.¹ The finding that matters for builders isn’t the number. It’s the cause. It’s rarely the model: the models are fine. It’s the system built around them, and in my experience shipping agents, that system fails in exactly three places.

I spend my days on one side of that gap: building agents against enterprise mainframes, where a plausible-looking wrong answer can reach a customer’s core systems, not a demo audience. That’s forced me to get concrete about all three layers, not just the one that happened to bite me first. To make it concrete here too, follow one running example: an agent modernizing Ledger, a legacy billing monolith, through all three.

Layer 1: Tools

An agent is only as reliable as the tools it calls. The failure that actually hurts isn’t a tool erroring (that’s loud, and you catch it immediately). It’s a tool succeeding with wrong data: search_code looks for every place Ledger calculates interest, quietly returns half the call sites, and reports success. The agent trusts it, and every step after is built on a wrong answer. No stack trace. It just drifts.

Most tool schemas can only say “succeeded” or “failed.” Add a third state, succeeded, but low confidence, and the agent knows when to stop and check instead of charging ahead:

# loose: fails quietly
tool(query: str) -> str | None

# strict: the third state is the whole point
tool(
    query: Enum[...],                # typed input
    on_error: Result | Failure,      # must be handled
    idempotent: bool = True,         # safe to retry
)

Pair that with idempotency, so a retry can’t double-apply a change, the way pressing an elevator button five times still sends the elevator once. The underlying rule is old and unglamorous: fail loud, not silent. A tool call built this way becomes something you can actually build on.

Layer 2: Memory

The default is retrieval-augmented generation: pull the relevant snippets, stuff them in context. That’s fine until relationships matter. The agent asks what depends on Ledger’s Balance module. RAG pulls the files that mention it directly and misses Overdraft, three hops away, the module holding the rule that overdrawn accounts don’t accrue interest. The output looks perfect. It compiles. It’s silently wrong.

The instinct is to build a complete knowledge graph of the codebase before trusting it. Resist that: teams stall for months trying to model everything. RAG is an index card, quick, cheap, and fine for an isolated fact. A knowledge graph is a subway map: what actually matters is how the stops connect. A shallow, one-hop dependency graph layered on top of RAG catches most of the silent drops, for a fraction of the effort. Go deeper only where it actually burns you.

Layer 3: Coordination

Once one agent works, the instinct is to add more. Ledger’s migration ends up with three: an analyzer, a migrator, and a validator. But more agents means more surface area for one failure to cascade: the analyzer is subtly wrong, the migrator builds faithfully on garbage, the validator rubber-stamps it. Gartner expects over 40% of agentic AI projects to be canceled by 2027, largely from missing exactly this: risk controls, not model quality.²

The fix isn’t a human in every loop (that just gets routed around). Think in bulkheads: a ship survives a flooded compartment because the compartments don’t share water, not because someone’s watching every one of them. Gate the irreversible steps, the ones that touch production, roughly 5% of what an agent does, and leave the rest autonomous. Delegate the work. Never the accountability.

Three-quarters of teams are now adopting agents. Only a small minority run them in real production.³ The gap between those numbers is these three layers. The teams that close it aren’t running a better model. They hardened the system around it.

Written alongside my upcoming talk at Commit Your Code 2026 (Sept 3), “The Three Ways AI Agents Fail.” Questions or corrections welcome — reach out.