88% of agent pilots die before production. But it's not the model's fault.

Everyone read the same headline this spring: 88% of agentic AI pilots never reach production. And almost everyone drew the same conclusion — the models aren’t good enough yet. I’m David Klippel, founder of dbexpertai, and I think that’s the wrong conclusion. Forrester’s breakdown in The State of Agentic AI in 2026 puts the failures on unclear success criteria, thin tool and data access, and evaluation drift. None of those are intelligence problems. They’re scoping and ownership problems. The teams that shipped agents to production didn’t have smarter models than the teams that didn’t — they had a narrower job, a clear definition of “correct,” and they risked looking stupid and having to roll back. I’m pretty sure they also had to iterate quite a bit.

I’ve been sitting with that number since it landed, because it maps almost exactly onto a decision my co-founders and I made two years ago — before we had the data to justify it. So this is a builder’s postmortem, not a pitch.

The 88% is real. The diagnosis is wrong.

Forrester’s finding is that roughly 88% of agentic AI pilots never reach production, and only about one in nine enterprises run agents in meaningful production at all. The gap between “we adopted agents” and “agents are actually running” is the whole story of 2026. The reflex is to blame model quality. But the reported blockers — evaluation gaps, governance friction, unclear success criteria — sit upstream of the model. A perfect model wired into an undefined job still fails the pilot.

This matters because the fix people reach for — wait for the next model — is the wrong thinking. Enterprise architects don’t have a capability problem. They have a scoping and evaluation problem.

What actually kills agentic AI pilots in production

I’m David Klippel, and I’ve watched enough of these projects die up close to know the profile isn’t low IQ. Agentic AI pilots die in production because no one defined what a correct outcome looks like, so evaluation is impossible; because the agent couldn’t reach the tools or data it needed to act; and because its behavior drifted between prompt versions with nothing to catch the regression. Forrester attributes the ROI failures to unclear success criteria, insufficient tool and data access, and evaluation drift — organizational faults, not model faults. In the same research, roughly 64% of teams name evaluation itself as the blocker that stalls the pilot.

The evaluation issue is where it’s at. The single most predictive signal that an agent will still be running in twelve months is automated evaluation on every prompt change — and most production agents don’t have that. If you can’t define “correct”, you can’t build the eval. If you can’t build the eval, every prompt tweak is a risk you don’t monitor. That’s not a model limitation. That’s a risky design decision that was never consciously made.

Why we built dbexpertAI on deterministic detection paths

We built dbexpertai on deterministic, expert-curated detection paths — not an open-ended agent turned loose on a database — specifically to shrink the evaluation surface. A read-only agent sits on-prem and runs root cause detection every 90 seconds across five SQL database systems: PostgreSQL, MySQL, MariaDB, Oracle, and SQL Server. Every detection path is a written-down investigation from Yoram Dan’s thirty-five years in relational databases. Same input, same output. When a path fires, it fires for a reason a human wrote down, and it comes with the diagnostic evidence attached.

That determinism is not a purity stance. It’s the thing that makes “correct” definable. Because a detection path is deterministic, I can regression-test it the way I’d test any other code: stand up a known-bad database state, run the path, and assert the exact root cause it should return. We automatically test at build time so new versions don’t regress. The eval surface is finite and inspectable. Contrast that with a probabilistic agent, where the same database and the same prompt can produce two different diagnoses on two different runs — and now your evaluation problem is unbounded.

One example I can share, anonymized: a set of checkout queries went from 40 milliseconds to roughly four seconds overnight. A probabilistic agent handed that symptom will very likely reach for the obvious story — the query is slow, add an index. Our detection path, sweeping read-only every 90 seconds, traced it somewhere else entirely: a bulk import had left the table’s statistics stale, the planner flipped to a sequential scan, and the fix was to refresh statistics, not to touch the schema. The path didn’t guess. It walked the same evidence chain a senior DBA does — wait events, plan changes, statistics age — and returned the root cause that Yoram Dan had written down years earlier. That’s the difference between a diagnosis you can trust and a plausible-sounding one you can’t.

The trust tax nobody prices into the pilot

There’s a cost that never shows up in the pilot business case: the trust tax. Every autonomous action an agent takes has to be logged, explained, and defended to an auditor or an on-call engineer at 3 a.m. Read-only, deterministic paths make that easy — the audit trail is the detection path itself, and it never mutated production to get its answer. Probabilistic agents that can write make it expensive, because now every action needs a post-hoc justification the system can’t reliably give.

This is where a lot of pilots quietly die between the demo and production. The demo looks magical. Then governance asks, “what will this thing do to production, and can you prove it after the fact?” and the honest answer is “mostly the right thing, and not really.” We made dbexpertai read-only (it does suggest actions your authorized lead can run, it doesn’t run them directly as of October 2026) and deterministic so that answer is “it cannot touch production, and every conclusion traces to a named investigation.” The trust tax is zero, which is the only reason autonomous diagnosis clears an enterprise change-review board at all.

What the 12% production AI agents that survive have in common

The agentic AI pilots that reach production — the surviving 12% — share four traits.

1. They have named ownership, so someone is accountable for the agent’s behavior.

2. They have scoped success criteria, so “correct” is a testable claim.
3. They have automated evaluation on every change, so regressions are managed.
4. They have the operational stomach to ship and roll back without treating rollback as failure.

That list is about scoping discipline, not about technology stack. You can run it on top of a frontier model or a deterministic engine — the discipline is what decides if your pilot can survive. We just found that deterministic detection paths give you three of the four traits almost for free: scope is baked into the path, evaluation is a regression test, and rollback is irrelevant because nothing was written. Feeding that output to an LLM for explanation and recommendations works very well. The responsibility for making changes still lies with the supervising human expert and in systems where it really matters, that’s likely to remain so for a few more years. I’d say we’ll see a gradual handover - first we’ll allow automated judgement with quality gates and automated checks on low-risk adjustments based on an allow list. Just like you would do with a Junior team member - you’d define what he’s allowed to do and what not. That grows with the reliability of the database expert as it should. If the expert is human or an AI seems the less important distinction.

The lesson learned

The 88% number isn’t an indictment of agents. It’s an indictment of shipping agents without a definition of correct. If you’re deciding how to put an agent into production this quarter, the highest-leverage work isn’t waiting for the next model — it’s narrowing the job until you can write the evaluation. The teams winning in production aren’t the ones with the smartest model. They’re the ones who made “correct” a testable claim before they shipped.
As a general rule I find: If the workflow has deterministic, clearly defined steps and rules then translate those into code before. If the decisions are (like often in databases) statistical in nature, use statistical models as the next layer. Surface all a human expert would need to make an informed decision. When you feed all of that including full context and relevant history into an LLM, you can get astonishingly accurate results. LLMs are genius but geniuses make the best decision with the information at hand. Make sure you provide that information.

Source: Forrester (Forrester Research Blog): https://www.forrester.com/blogs/the-state-of-agentic-ai-in-2026-companies-are-chasing-few-are-catching/