Why 76% of AI agent pilots stall, and how your Agentic ITOps pilot can avoid the same fate

The debate is no longer whether AI belongs in ITOps; it’s about how quickly it can be implemented, how to measure it, and who’s accountable when it acts. And although IT leaders across industries are scrambling to integrate agentic AI into their operations, those deployments are facing serious challenges.

A new Harris Poll survey of more than 300 U.S. data and AI decision-makers puts a number on the problem. Nine in ten organizations are actively deploying autonomous AI agents, but 76% have hit critical roadblocks moving those agents from pilot into full production.

If you lead IT operations, those stats probably don’t surprise you. You’ve likely watched a promising proof of concept quietly stall somewhere between the demo environment and the 2 am Sev1 outage.

One particularly interesting part of the research is that most respondents don’t blame the models themselves; they blame the data underneath them. That’s good news for ITOps, because the data these AI agents need already exists inside your enterprise. It’s just scattered across tools, tickets, chat threads, and the heads of your most experienced engineers.

In this article, we’ll break down what the research found, why ITOps feels these roadblocks more acutely than most functions, and how a solid data foundation helps you avoid four of them. Then we’ll share why we recommend Major Incident Management (MIM) as the starting point for deploying Agentic ITOps.

What the Harris Poll research found

The Harris Poll surveyed director-level and above leaders in data, privacy, and AI in August 2026. The results paint a consistent picture that agentic ambition is outpacing the foundation required to reliably run AI agents.

A few findings stand out:

Taken together, these numbers result in an expensive “verification tax.” Every agent your teams can’t fully trust creates a new cycle of manual checking, correcting, and second-guessing. Add enough agents, and your people spend more time supervising automation than the automation ever saved them. At that point, the business case collapses.

These findings line up with broader industry signals, too. Gartner reports that enterprises abandon at least half of generative AI projects after proof of concept, citing poor data quality, rising costs, and weak risk controls. Gartner also predicts that organizations will cancel more than 40% of agentic AI projects by the end of 2027.

To be fair, this is one survey, with a margin of error of about 6.4 points. But it reinforces what we hear from enterprise IT leaders in the field.

Why ITOps feels the verification tax more than anyone

In most business functions, incorrect agent output results in rework. Someone rewrites the email, fixes the summary, or reruns the report. This is annoying and time-consuming, but survivable.

In IT operations, the stakes are much higher, and a wrong output has a blast radius. A misrouted page can add 20 minutes to a Sev1 incident, and major outages cost enterprises up to $25,000 per minute. That’s half a million dollars, gone. A stale ownership record pulls the wrong team onto the bridge. A bad change recommendation causes the next outage. Each of those mistakes costs you revenue, SLAs, and customer trust.

ITOps also has a unique context problem: your environment never stays still long enough for anyone to verify it. Services change owners, topologies drift, and teams ship changes every hour. AI-assisted development only speeds that up, so a snapshot of context starts to go stale the moment someone takes it. So when 87% of leaders say they keep re-verifying their agents’ context, ITOps teams should take that as a warning. If your agents depend on static, manually-maintained context, the re-verification cycle never ends.

We’ve seen this movie before. For years, the industry assumed automation required perfect data. Clean the CMDB, normalize every source, and get the foundation “right” before doing anything else. That multi-year project became the reason automation stalled, and a big part of why nobody solved the $250 billion problem of manual ITOps. Despite steady growth in observability and ITSM spending, end users still report 65% of all incidents before monitoring catches them.

 

That’s our concern with how many organizations will read this survey. If the takeaway becomes “clean and govern every data source before you scale,” you will never successfully scale Agentic ITOps. There are four roadblocks you must overcome to ensure your organization succeeds with these initiatives.

Roadblock 1: “Our data foundation isn’t ready”

This is the problem we hear most often, and the research backs up the worry. The Harris Poll survey found that 72% of decision-makers said their AI shortfalls almost always trace back to a poor or unaligned data foundation. Understandably, many leaders conclude that their data must be clean, complete, and centralized before an agent can touch it.

However, in ITOps, the real issue isn’t missing data. It’s giving AI agents the ability to synthesize and use the critical context that lives in places rules-based automation could never read. The knowledge your teams need to resolve most incidents already exists inside your enterprise, spread across four kinds of sources:

Agentic AI flips the relationship between data quality and automation. Instead of treating clean data as the price of admission, it treats data quality as an output. Agentic AI agents can observe patterns, infer relationships, and fill gaps through daily operations. Every incident they touch strengthens the knowledge layer underneath them.

That’s the job of the BigPanda IT Knowledge Graph. It continuously ingests and connects data from those fragmented sources to build a living model of your IT environment. It builds a living model of what depends on what, who owns which service, what changed recently, and what worked the last time something similar broke. Your CMDB simply becomes one input among many, not the single source of truth that everything else depends on.

Roadblock 2: “We can’t trust the context our agents are working with”

In the survey, 87% of decision-makers said their teams regularly re-verify that their agents’ context remains accurate and up to date. That habit makes sense in organizations where people have to maintain that context by hand, and everyone knows how fast hand-maintained records fall out of date.

The fix isn’t requiring more verification; it’s building context that keeps itself current. Because the IT Knowledge Graph learns from live operations, every incident enriches it with fresh context. When a responder corrects an ownership record mid-incident, or when a post-mortem identifies a new dependency, the graph learns. The system gets more accurate as your teams use it.

Here’s what that translates to in a major incident. An AI incident assistant has to answer four questions in seconds:

1. What changed?
2. Who owns this service?
3. What does the topology say about blast radius?
4. How did we fix this last time?

If those answers come from a spreadsheet that someone updated last quarter, your responders will have to manually re-verify each one. If they come from a knowledge layer that ingested this morning’s changes and last week’s bridge-call transcript, your responders can act on them immediately.

We also recommend a simple rule of thumb: let AI reason where your knowledge foundation is dense. Start with services that have validated topology, rich incident history, and connected change data. Before you scale any agent in ITOps, run a quick self-check:

• Can you trace an alert to a service, and that service to business impact?
• Does your change data connect to incident response?
• Can responders search past post-mortems during an incident, not just after?

If you answered “no” to any of these, you’ve found your first data foundation project. The good news is that the project will be much smaller than a CMDB overhaul.

Roadblock 3: “Our people spend hours checking the agent’s work”

Just over half (51%) of the survey’s respondents said their teams have to spend significant staff hours reviewing and correcting agent outputs before they go live. That’s where pilots quietly die, because if your senior engineers have to review every agent output forever, you haven’t really automated anything. You’ve just added another step to your process.

Manual reviews aren’t necessarily the enemy, because early on in any agent deployment, you should absolutely require them. The real problem is endless manual reviews with no exit plan. You want a system where the need for reviews shrinks as the agent earns trust, and where you can reliably measure that trust.

At BigPanda, we recommend advancing autonomy one stage of the incident lifecycle at a time.

Please note that if a vendor promises fully autonomous remediation on Sev1 incidents in month one, treat it as a red flag, not a differentiator. Every serious platform still routes high-risk production changes through human approval, and for good reason.

Roadblock 4: “Nobody owns the move from pilot to production”

The survey found that more than half of organizations moved their AI function closer to the data organization over the past year. That makes sense for managing data risk, as governance teams should absolutely help define what agents can access and how you audit their decisions.

But in IT operations, someone also has to own the outcomes that these agents deliver. Somebody has to decide when an agent graduates from shadow mode to the live war room, and somebody has to answer for MTTR when it does. A center of excellence can advise, but it can’t own a Sev1.

We recommend naming your major incident manager, or the head of IT operations who owns that function, as the accountable owner. They already own the process that agentic AI is transforming; they already have authority in the war room, and they already answer for the metrics that matter. Put an executive sponsor above them and clear phase exit criteria below them.

So what does that owner actually do?

• Runs a short promotion review after every major incident, moving each lifecycle stage up or down based on performance.
• Encodes your existing comms, escalation, and approval protocols into incident-type templates, so AI fits your process instead of replacing it.
• Adds a “grade the assistant” step to every post-incident review and feeds corrections back into the knowledge foundation.
• Delivers the scale-or-stop recommendation at the end of the pilot.

Your incident commanders and senior SREs carry your institutional knowledge, and they need to hear early and often that the assistant captures and amplifies their expertise. The payoff for them is real, such as fewer 2 am bridge calls, fewer unnecessary pages, and post-mortems that write themselves.

Begin your Agentic ITOps journey where the value is concentrated: The major incident

Every roadblock above gets easier when you pick the right first use case. You want something valuable enough to matter to the business, contained enough to govern, and fast enough to prove value before pilot fatigue sets in. In our work with large enterprises, that’s Major Incident Management.

• The value is concentrated. Every hour of a Sev1 carries a measurable cost in bridge call hours, SLA exposure, and revenue put at risk.
• Trust is gradable. The assistant earns autonomy one interaction at a time, across context, coordination, communication, and documentation, rather than demanding it all at once.
• It requires no restructuring. The AI Incident Assistant works inside the tools your teams already use, such as Microsoft Teams and ServiceNow, so you can deploy it and see value rapidly.

Here’s what that looks like in practice. A Fortune® 500 global hospitality enterprise was two hours into a major incident, running the traditional playbook. Dozens of responders sat on the bridge while the incident commander went around the horn team by team, and everyone hunted for information that no single individual had. Then the team handed the investigation to the AI Incident Assistant’s Swarm Investigation feature.

Multiple agents fanned out across their systems, collected evidence, reasoned over what they found, and went back out with follow-up queries informed by each other’s findings. The assistant surfaced the root cause in roughly fifteen minutes.

Two hours of human hunting was cut down to fifteen minutes of agentic investigation, and and the team didn’t have to rip out a single tool to get there.

If you’re ready to integrate agentic AI into your ITOps, check out our new ebook, The Four Decisions: A 90-Day Leadership Playbook for Agentic ITOps. This guide walks you through the scope, autonomy, metrics, and ownership decisions that separate production programs from stalled pilots. It also includes a phase-by-phase plan for your first 90 days.

Get your copy today, or see the AI Incident Assistant in action.

5 key takeaways from this article:

1. Most AI agent programs stall on data, not models. Nine in ten organizations are deploying AI agents, but 76% hit critical roadblocks moving to production, and 72% trace AI shortfalls back to a poor data foundation.
2. The verification tax is really a context problem. Teams re-verify agent context and review agent outputs because they maintain that context by hand.
3. Don’t answer a data problem with a multi-year data project. Agentic ITOps treats data quality as an output, building a living knowledge layer from the observability, ITSM, incident, and collaboration data you already have.
4. Make trust measurable. Advance autonomy one lifecycle stage at a time, track human override rates, and use circuit breakers to demote any stage that slips.
5. Start with major incidents. It’s the most contained, highest-value path out of pilot purgatory, and it doesn’t require restructuring how your teams work.