The Agent Deployment Gap: What the 2026 Data Says About Why Pilots Die

TL;DR

Enterprise agents mostly don't fail to reach production because the model isn't good enough. They stall because nobody can answer the governance question the agent's usefulness actually depends on: what is this agent allowed to touch, and how would we prove what it did.

The survey data on this is noisier than most of what gets quoted from it. Several of the most-repeated numbers about pilot failure rates and average ROI don't trace back to a report anyone can actually locate, and one widely cited figure turns out to be measuring something other than what it's cited for. We think that's worth saying plainly, not repeating with a footnote.

What does hold up, because it comes from surveys that publish their methodology: experimentation with agents is close to universal, and the governance work behind it, access scoping, monitoring, named accountability, is mostly not done. Gravitee finds barely one organization in five has agents fully governed before going live.

This isn't an argument that agents are hard to build. It's an argument that shipping one is mostly an authorization problem wearing an engineering costume, and that problem is solvable before you write the agent, not after.

Overview

The pilot that demoed well in March, entered security review in April, and is still sitting there in September shows up constantly in the 2026 survey data as the median case, not the exception. Okta's AI Agents at Work 2026 survey found 92% of executives describing agents as in widespread or moderate use at their organization. Production tells a different story, and the instruments measuring it don't agree with each other. Google Cloud's 2026 survey of 3,466 senior leaders across 24 countries put deployment at 52%. Fivetran's own Agentic AI Readiness Index finds 41% of surveyed data professionals already running agentic AI in production, while only 15% at the same organizations call themselves fully prepared to support it there. Three instruments, three different numbers, and one of them contradicts itself.

Two posts on this site cover what happens when agents behave badly: the compliance cost of uncontrolled agents, and the real cost of rogue actions. This post is about the opposite failure, agents that never behave badly because they never ship.

The next section runs the primary sources down one by one: Gartner's actual wording against how it gets quoted, the webinar poll its investment breakdown is built on, and the root-cause split that gets cited for a question it was never measuring. What survives that process is smaller than the commentary built on top of it.

The Numbers, With Names Attached

Here's the 2026 data as it actually stands, sources attached, soft claims marked as soft.

Gartner published the most-quoted forecast on 2025-06-25, and its exact wording is worth preserving: "Over 40% of agentic AI projects will be canceled by the end of 2027, due to escalating costs, unclear business value or inadequate risk controls." That's a disjunction, any one of the three suffices, and it usually gets flattened to an "and" in retelling, which changes the claim. The same release introduced "agent washing", vendors rebranding assistants, RPA and chatbots as agentic, and estimated only around 130 of the thousands of self-described agentic AI vendors were building something genuinely agentic. Gartner's investment breakdown came from a January 2025 poll of 3,412 webinar attendees: 19% significant investment, 42% conservative, 8% none, 31% waiting or unsure. That's a webinar poll, not a sampled survey, and Gartner doesn't present it as one.

A great deal of commentary built on top of that forecast cites a figure for how many pilots never reach production at all, plus a root-cause breakdown for the ones that ship and then disappoint. We went looking for the primary reports behind both. Neither is locatable. The pilot-failure number circulates in at least three different versions attributed to three different research houses, and the root-cause split gets quoted constantly with its actual denominator quietly dropped: it describes causes within a minority of shipped deployments reporting negative returns, not causes of pilots that never shipped, which is what it's almost always cited to support. We're not using either number here. Treat any version of it you run into elsewhere the same way.

Data quality gets called the top adoption barrier constantly, and the one aggregation with a citable methodology behind it, Digital Applied's roundup of more than 120 enterprise data points, says something different: data quality and access sits fourth, at 49%, behind evaluation and observability at 64%, governance and compliance at 57%, and model reliability at 51%. The three barriers ranked above data quality are governance and measurement problems, not data problems, which matches the argument the rest of this post makes. A separate 52% figure for data quality circulates in most roundups with no attribution we could trace. We're leaving it out.

Fivetran's own index (400 data professionals at organizations with 2,000-plus employees, published 2026-05-05) is the clearest instrument here, because it's internally consistent about being inconsistent: 41% already running agentic AI in production, 15% calling themselves fully prepared to support it there, and nearly 60% reporting investment in the millions to tens of millions. Ready and running are not the same claim. This is one survey admitting it.

Governance data is where sourcing gets genuinely good, because these surveys publish enough methodology to check. Gravitee's State of AI Agent Security 2026 (750 respondents, CIOs, CTOs, VPs of engineering, heads of platform, UK and US, April 2026) found only 19.7% of organizations say all their agents are fully secured and governed before going live. Mean monitoring coverage across the sample was 52%, meaning roughly half of production agents run unmonitored. Only 7.2% had a named individual formally accountable for agent behavior, and 32.4% described accountability as unclear or situation-dependent. Okta's AI Agents at Work 2026 (Apprize360, March 2026, 292 executives and 492 knowledge workers across seven countries) found only 34% of organizations applying the same security controls to agents that they apply to human employees.

For historical context, MIT's Project NANDA report The GenAI Divide: State of AI in Business 2025 (July 2025) is worth reading directly rather than through its retellings, for reasons the next section gets into. Its evidence base is a review of 300-plus publicly disclosed AI initiatives, structured interviews with 52 organizations, and 153 leadership survey responses.

19.7%

organizations say all their agents are fully secured and governed before going live

52%

mean monitoring coverage across surveyed organizations' production agents

7.2%

organizations with a named individual formally accountable for agent behavior

Reading Them Skeptically

Now the part most statistics roundups skip.

Ask who ran the survey and what they sell. Fivetran sells data movement, and its readiness index finds companies aren't ready because their data isn't ready. Gravitee sells agent governance, and finds agents ungoverned. Okta sells identity, and finds agents lack identity controls. None of that makes the findings false, several of these are the best-instrumented data available and transparent about method, but a survey's question set is designed by someone with a hypothesis, and the hypothesis tends to resemble the product.

Ask what "in production" means. No two of these surveys define it the same way, and most don't define it at all. Is an agent in production when it serves external customers? When it runs unattended? When it has a change-management process behind it? Fivetran's own contradiction above, 41% in production and 15% ready, is as much a definitional gap as an empirical one. The same ambiguity infects "pilot." A week-long proof of concept and a funded six-month program with a business sponsor both get counted, and lumping them together inflates the failure rate with experiments that were never meant to ship.

Watch where drift starts, because it's usually earlier than the citation chain. MIT's Project NANDA report says, plainly, that 95% of organizations pursuing generative AI initiatives are getting zero measurable return. That's the actual finding. Forbes' widely shared coverage of the same report ran under the headline "MIT finds 95% of GenAI pilots fail." Those are different claims wearing the same number. One is about organizational return across a portfolio of initiatives; the other implies nineteen out of twenty individual pilots don't work, which the report never measured. The drift happened at the second link in the citation chain, not the twentieth, and once a wrong headline number is loose, everyone downstream inherits it without re-checking.

Be skeptical of self-reported return figures generally, for a reason that has nothing to do with any specific number: they're reported by the people who sponsored the project, with no control group, no agreed baseline, and no outside auditor. A return figure computed only over deployments that shipped also excludes, by construction, everything that didn't, which is most of what happened. We'd trust a negative-outcome figure more than a positive one, because nobody has an incentive to report it generously.

Note what the good data is about. The figures with published methodology and unambiguous definitions are overwhelmingly about governance: monitoring coverage, named accountability, whether agents carry an identity at all. Those are the numbers worth acting on, and they point one direction.

Nobody Defined Done

Take the cause we think matters most, on its own terms rather than a survey's word for it. "Unclear success criteria" sounds like a project-management complaint, which is why it gets skimmed. In agent work it's a technical failure with a specific mechanism.

Consider a contract-review agent at a services firm, a hypothetical carried through the rest of this post. The stated goal is "reduce legal review time on inbound vendor contracts." The pilot looks like a success: legal counsel reads the agent's summary of a master services agreement and agrees it caught the indemnity cap and the auto-renewal clause. Everyone's pleased.

Now try to write the acceptance test. On which corpus? Against what baseline, the median reviewer, or the reviewer at 5pm on a Friday? What's the tolerable false-negative rate on a missed liability cap, given that the cost of one miss isn't symmetric with the benefit of a hundred hits? None of these have answers, because the goal was a direction, not a specification.

Without that specification, three things follow. There's nothing to evaluate against, so no regression suite exists. There's no threshold at which the agent is finished, so scope expands to fill available time. And when the reviewer asks how good it is, the honest answer is a demo. Demos don't clear review gates. The tell for this failure is a pilot whose success is described entirely in adjectives.

The Access Problem

This is the most under-discussed cause, and it's the one that connects the survey data to the governance data.

Insufficient access reads, on first pass, like a plumbing complaint: the connector wasn't built. It's almost never that simple. The contract-review agent works beautifully on the fifty PDFs someone dropped in a folder. To be useful it needs the contract repository, which means read access to a corpus that includes contracts the requesting user isn't cleared to see. It needs the CLM system to check which clauses were previously negotiated. To be genuinely useful, it needs to write a review note back. Every one of those is blocked not by engineering but by an unanswered governance question:

• Whose access is it using? A service account with repository-wide read can surface a contract to a user who shouldn't see it. Borrowing the requesting user's access means the design has to carry two identities, the human's and the agent's, and enforce their intersection, which most agent frameworks simply don't do.
• What's the write blast radius? Read access is a confidentiality question with a known shape. Write access to a system of record is a different conversation with a different approver, and it's usually the conversation that stalls.
• Who approves it, and against what standard? The team asks for access. The data owner asks what controls exist. The team describes prompt instructions. The data owner declines, correctly.
• What happens when it's revoked? If nobody can say which credentials the agent holds or how they'd be cut off, nobody grants them in the first place.

Figure 2 — Access as a two-identity problem. The agent's own permissions are necessary but not sufficient; the request also has to carry who asked, so the gateway can enforce the intersection rather than the agent's ceiling.

The pattern is consistent: teams grant broad permissions during a pilot because it's fast and the environment is contained, then discover at production time that they can't justify those permissions and can't narrow them without redesigning the agent. The pilot's convenience becomes the production blocker. That's why "insufficient access" and "governance friction" are the same finding measured twice.

Demo Reliability

Agents look fine in a demo and aren't fine at scale. The reason is arithmetic, not luck.

The τ-bench work (arXiv:2406.12045) introduced pass^k: the fraction of scenarios an agent solves on all k independent attempts, not at least one. The widely cited illustration is GPT-4o on the retail domain, 61.2% pass^1, with pass^8 dropping below 25%. The task didn't get harder. The measurement got honest. Multi-step tasks compound the same way. If each step independently succeeds 95% of the time, a ten-step workflow completes about 60% of the time and a twenty-step workflow about 36%. The contract-review agent's demo was one document, one reviewer, one happy path. Production is four hundred documents a month, most of them not master services agreements, some scanned, several in French.

The demo is a genuine result. One attempt, one path, read by a reviewer as evidence of reliability it never claimed to have. A good share of the deployment gap lives in that space between what the number is and how it gets read, and the only way to close it is to measure consistency across repeated, varied attempts before anyone sees a slide.

Evaluation and Ownership

Two causes that look separate are the same organizational absence.

No evaluation means no ability to change anything safely. Without an evaluation suite, nobody can tell whether last week's prompt change, model upgrade, or tool-description tweak made things worse. Agents are unusually sensitive to changes that look cosmetic: a reordered tool list, a reworded description, a provider's silent model update. A team without evals experiences this as mysterious intermittent regression and stops shipping. The agent doesn't get killed in a meeting. It decays.

Unclear ownership bites hardest exactly where the agent touches something regulated. Gravitee's 7.2% is the most alarming figure we've cited, because ownership is the cheapest thing on this list to fix. When the contract-review agent needs to write into the CLM system, "who signs off that this is acceptable" has to resolve to a person. If it resolves to "the AI working group," it doesn't resolve, and the review stalls between a platform team that owns the runtime, an application team that owns the prompt, a data owner who owns the corpus, and a risk function that owns the consequence. None of them can approve the whole thing alone.

The Last Mile

Which brings us to the failure mode nobody puts on a slide, because it isn't a decision: the working agent that stalls indefinitely in security review.

The mechanics are mundane. The agent does the task. It enters review. The reviewer asks what reviewers ask: what can it access, what can it do, what's logged, who's accountable, how do we turn it off, what happens if it's prompt-injected. The team, having built the agent first and thought about governance second, answers some of these with design intent instead of controls. The reviewer doesn't reject the agent, rejecting things is career-limiting and possibly wrong. The reviewer asks for more information. The team gets reassigned to next quarter's priority. The agent is still in review a year later, and it shows up in no statistic as a failure.

The security concerns are legitimate, which is what makes this hard. The Agent Red Teaming results (arXiv:2507.20526), 1.8 million prompt-injection attempts against 22 frontier agents across 44 scenarios, with more than 60,000 eliciting policy violations and nearly all agents violating policy for most behaviors within 10 to 100 queries, describe an attack surface a reviewer is right to worry about. The problem isn't that review is too strict. It's that the artifacts review needs were never produced.

Figure 3 — The attrition funnel, by mechanism rather than by measured weight. This is our reading of where each cause bites, not a percentage from a survey; no locatable instrument measures loss at each stage separately, and the last stage is missing from most datasets because "still in review" is never recorded as a failure.

What Shortens the Path

The teams that ship do a small number of unglamorous things early. None of this is novel. The point is the sequencing.

Deploy narrowly first. One document type, one team, one system, read-only. A narrow first deployment isn't a smaller pilot, it's a smaller production system, and it exercises the whole path: review, logging, ownership, rollback. Narrow scope also keeps the write blast radius and the access negotiation small enough that they don't become the thing that stalls the project.

Define the audit and permission story before the demo. Write down, before building, which systems the agent will touch, whose authority it acts under, which actions are read and which are write, which require a human, and what a log line looks like. That document is the input to review. It takes a day, and it turns review from an interrogation into a check.

Treat access provisioning as part of the build. Put credential design, scope negotiation with data owners, and the revocation path on the plan, with dates and owners. If access will take six weeks to negotiate, that's a six-week task, not a surprise.

Make evaluation a precondition, not a phase. Build the eval set from the corpus you'll actually run against, including the scanned French contracts, before the agent works, and measure consistency across repeated attempts rather than best-of-n.

Name one accountable person. Not a committee, not "the platform team." One name, before the first line of code.

At Agentic Fabriq the access half of this is what we build for: default-deny scopes across organization, team and member, an effective tool list computed as the intersection of the user's scopes and the agent's, action-level permissions enforced in the backend rather than described in a prompt, and both identities carried on every request so audit logs answer the reviewer's question directly. That's narrowly the answer teams lack when a data owner asks what controls exist.

Conclusion

The 2026 data is worth reading and worth discounting, often in the same sentence. A meaningful share of the widely repeated numbers don't trace back to a locatable report, and at least one traceable case turns out to be attached to the wrong claim entirely. What survives scrutiny is the shape: adoption is near-universal, production is rare and inconsistently defined, and the causes that actually explain the gap, when you look at the surveys that publish enough methodology to check, cluster on specification, access, evaluation and ownership rather than on model capability.

That shape has a practical reading. If agents failed for capability reasons, the correct strategy would be waiting for better models. They don't, so waiting isn't a strategy. The work that moves an agent from a good demo to a running system is deciding what it may touch, proving what it did, measuring whether it still works, and naming who's responsible. None of that gets easier with a larger model.

Sources

• Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027 — Gartner, 2025-06-25
• "Agent washing" is here: most agentic AI tools are repackaged RPA — IT Pro
• Why 40% of Agentic AI Projects May Be Canceled by 2027 — Forbes, 2026-07-07
• State of AI Agent Security Report 2026 — Gravitee (750 respondents, UK/US, April 2026)
• AI Agents at Work 2026: Securing the agentic enterprise — Okta (Apprize360, March 2026)
• Google Cloud study: 52% of executives say their organizations have deployed AI agents — National Research Group, 3,466 leaders
• Fivetran launches 2026 Agentic AI Readiness Index (400 data professionals, 2026-05-05) — Fivetran
• The GenAI Divide: State of AI in Business 2025 — MIT Project NANDA
• MIT finds 95% of GenAI pilots fail because companies avoid friction — Forbes
• AI Agent Adoption 2026: 120+ Enterprise Data Points — Digital Applied (the aggregation examined in this post)
• τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains (arXiv:2406.12045)
• Benchmarking AI agents for the real world — Sierra
• Security Challenges in AI Agent Deployment: Insights from a Large-Scale Public Competition (arXiv:2507.20526)
• The AI Agent Governance Gap: What CISOs Need Now — Cloud Security Alliance