Why enterprise agentic AI programs stall before they scale

Insights

• Agent development accounts for only 30% of what it takes to scale agentic AI. The other 70% is where most programs stall.
• Four areas are behind that stall: organizational alignment, security and compliance, platform integration, and stakeholder conviction. These are largely unaccounted for in planning.
• Enterprises need a formal readiness check across all four areas. This is what tells an enterprise it's ready to scale.
• Success depends less on how advanced the agents are, and more on how well the enterprise plans for everything around them.

Agentic AI is generating more attention and adoption than almost any recent enterprise technology. Companies are investing heavily to bring agents into production. According to IDC, over a billion AI agents are expected to be deployed by 2029, executing roughly 217 billion actions a day. Agentic AI is set to dominate worldwide IT spending, reaching $1.3 trillion in 2029. Yet 80% of enterprises remain in exploring or emerging stages of agentic AI adoption, with only 14% able to scale programs. Across AI implementations, fewer than 25% succeed in delivering business value, while nearly 40% are canceled outright or fail to meet their goals. All that investment, but limited results. Why?

Most agentic AI programs start with the same assumption: get the technology right and the rest will follow. Boards approve budgets, chief technology officers finalize the platforms where agents will run, and delivery teams assemble the first wave of agents, assuming the hard part ends once agents are built and models are selected. Scaling becomes a matter of replication: prove it in one workflow, extend it everywhere else. It's the same approach enterprises used for earlier software programs: build first, scale later.

But agentic AI programs don’t work that way. Based on Infosys experience across more than 50 agentic AI deployments, agent development and testing accounts for only 30% of the total effort involved in building an agentic AI-enabled enterprise — the visible tip of the iceberg. The remaining 70% sits below the surface: organizational alignment, security and compliance, platform integration, and stakeholder conviction (Figure 1). These areas are often underestimated during planning, and this is where three-to-six-month delays, budget overruns, and scope cuts tend to originate.

Figure 1. Agentic AI's iceberg: what’s visible, what’s beneath

Source: Infosys

Agentic AI’s 70/30 problem

Each of the four areas that comprise the 70% of program effort carries its own failure patterns, and each is largely absent from how programs are planned and staffed today.

Organizational alignment

Budgets for AI programs get locked in long before anyone fully understands what an agentic AI initiative would require, so the program arrives mid-cycle with no one owning the funding end to end. According to a joint research by Infosys and HFS, one in five enterprises pursuing agentic AI is still determining ownership of outcomes. Secondly, most enterprise processes were built assuming predictable, rule-based systems, but an agent doesn't work that way. It exercises judgment, hits exceptions, and needs escalation paths. Every existing process the agent touches must be pulled apart and rebuilt to handle ambiguity it was never designed for, which means working in close collaboration with operations teams. Complexity increases further when a third party manages those operations.

To add to these challenges, most of these processes were never properly documented or owned in the first place, so a lot of what looks like alignment work is really discovery work, which requires figuring out how a process runs before it can be redesigned. According to Infosys experience, a single use case can easily reach four to six enterprise systems, each owned by a different team, on a different release cycle, with its own backlog. When talking about a program with an average of six use cases, that spans somewhere between 15 and 20 systems. Coordinating all those workstreams can take as much effort as building the agent itself.

Security and compliance

AI regulations vary across regions and continue to evolve. Furthermore, agentic AI programs must meet certain standards to ensure fairness, bias mitigation, explainability, and auditability. This means that security and compliance teams end up building for the rules that exist today while also considering the ones they expect tomorrow, all at once. These teams usually scope their year around a fixed portfolio of work, and agentic AI shows up as unanticipated, mid-cycle demand that nobody budgeted for. This adds entirely new risks, like prompt injections, which involve an agent being manipulated through the very instructions it's supposed to follow, misuse of the tools that agent has access to, or overstepping the actions it is allowed to take. Review processes built for ordinary applications simply aren't designed to catch any of that. As a result, a security review that normally takes two weeks can stretch between eight and 12 weeks for an agentic AI system.

And underneath all of it sits a more basic problem: agents need secure, authenticated access into enterprise systems which involve proper application programming interfaces (APIs), gateways, and identity controls: most systems were never built with that kind of access in mind. Building it takes money and time, and that competes with everything else security is already funding.

Platform integration

Agentic AI platforms are rarely production-ready at program kickoff and undergo regular updates that impact the foundation the agents run on: how they reason and coordinate, what they remember, how they call external tools, and the guardrails and testing that keep them safe. Enterprises building on top find their agents behaving differently as that foundation shifts underneath them. Programs that commit to a platform under this pressure often find themselves choosing between three imperfect paths: stay the course and accept vendor-driven delays, pivot to open source and take on re-engineering risk, or go hybrid and absorb more integration complexity. There's no clean option. Each path trades one risk for another and adds to the noncoding 70% rather than shrinking it.

Moreover, if the platform isn't ready, the delay doesn't stay contained. According to Infosys experience, whenever platform integration slips, resource capacity from dependent teams gets reallocated elsewhere, and once that capacity is gone, it's rarely recovered. Of everything that can go wrong in an agentic AI program, this is often the hardest to walk back, because a platform delay can destabilize the whole integration ecosystem the program was built on.

Stakeholder conviction

Most stakeholders have only ever seen a chatbot or a demo. They usually do not have practical exposure to a multiagent system operating across a live workflow. That gap in understanding makes it harder for them to weigh in with confidence on rollout decisions, risk trade-offs, or where to draw the line on autonomy. Closing it takes more than a walkthrough or “hello-world” demonstrations. It takes real proofs of concept with the system's limitations, failure modes, and guardrails made explicit rather than glossed over.

How agents get introduced compounds this: sequencing and pacing are business decisions but require a decent technology understanding, and rolling out dozens of agents at once carries a very different risk profile than phasing them in by function, product line, or customer segment. That decision shapes how much trust the organization builds.

Also, too often success measures like efficiency, quality, adoption, and business outcomes are defined only after the agents are already built. Without these measures agreed upfront, there's no shared way to tell whether the program is working, and no shared commitment to scale beyond pilots.

Build the readiness gate

The four complications described above share a common root: readiness gets assumed but not verified. The solution is to agree on what ready to scale means. Instead of treating agent development as the milestone that unlocks scaling, enterprises need to establish a strategy to have a formal gate, one that tests enterprise readiness across each of the four domains: organizational alignment, security and compliance, platform integration, and stakeholder conviction with the same rigor currently reserved for testing the agent itself.

Risk cannot be eliminated altogether, but the readiness gate helps measure and reduce it (Figure 2). Each item on the domain is scored on a maturity scale — absent, documented, piloted, operational, operational-and-enforced. The domain score is the average across its items, with one rule: no single item can score below 40. That floor stops a strong average from hiding a capability that's missing entirely. Each domain needs to score 60 to pass the gate. Below 60, the risk is structural and shows up in delays that delivery discipline alone cannot absorb. Above 60, the remaining gaps are executional and can be closed alongside the build rather than blocking it. That’s what makes this a strategy rather than a checklist: if a domain falls short, the program pauses scale-related work and closes the gap first, instead of proceeding anyway.

Figure 2. Enterprise readiness gate at 60 for each domain

Source: Infosys

Agent placement: the gate’s clearest test case

Nowhere does this discipline matter more than in a decision most programs never formally make early on: where does the agent live? There are three options:

1. Run the agent on the enterprise's central platform for consistency, shared governance, and reuse across use cases. But this comes at the cost of being bound to that platform's pace and limitations.
2. Run natively on the underlying system it serves, for speed and data proximity. But this is harder to govern centrally and harder to replicate elsewhere.
3. Design a deliberate hybrid, splitting responsibilities between the two to balance speed against control.

A few practical signals tend to drive the answer. First, how often the agent needs to reach across platform boundaries matters: cross-boundary calls above roughly 30% of interactions favor centralizing on the enterprise platform, while lighter cross-boundary traffic favors deploying natively.

Response time counts too. Real-time interactions under 200 milliseconds require platform-native deployment, while multistep reasoning that can tolerate a second or more fits the enterprise platform better.

And where sensitive or regulated data lives also shapes the call. It is generally safer to keep sensitive data platform-native, reserving the enterprise platform for aggregated, cross-system analysis.

The strategic point is that the gate requires the question to be asked and answered explicitly, every time, rather than left to inherit whatever the first integration made convenient. That single discipline of deciding placement on purpose, with the trade-offs visible, is what keeps technology readiness from becoming the next hidden cost, and it's the same discipline the gate applies across all four domains.

Steps to apply the readiness gate

Treat the hidden 70% as the critical path changes what gets planned, funded, and staffed from day one. Six moves bring that shift into practice:

1. Plan and budget for the full 100% of program effort

Stop scoping agentic AI programs as if agent development were the whole job. Build the strategy, the timeline, and the budget around all four readiness areas from the outset.

2. Start security and compliance at concept stage

Consider security before the architecture is set. Give security teams agentic-AI-specific threat models, guardrails, and reference architectures to work from, rather than routing agent programs through a generic secure-by-design checklist that assumes a fixed set of threats and a deterministic system to test against. Agentic AI breaks that assumption: agents act autonomously, call tools, and make judgment calls that traditional security models were never designed for.

3. Align stakeholder teams early

Informed leaders make faster decisions, unblock issues earlier, and turn into genuine sponsors of the program. Building that awareness must happen before development starts. Get funding owners, process owners, and the teams whose systems the agent will touch into the same room to have these stakeholder conversations as per the program schedule, and not as a reaction to delays.

4. Validate platforms before committing

Insist on hands-on proof that the platform connects to enterprise systems with real integrations, real data flows, and real security patterns tested end-to-end, rather than taking the vendor's roadmap on faith.

This is also where vendor lock-in needs to be addressed. Infosys research on getting agentic AI to production grade found that enterprises must avoid the lock-in trap by architecting for a poly-cloud, poly-AI foundation from the outset. In this format, governance, orchestration, and agent selection are designed to work across vendors, rather than being retrofitted onto a single-vendor build. Hence, make the build, buy, or hybrid decision, including where each agent will live, deliberately, before the first use case forces a default.

5. Design rollout like a phased product launch

Segment the users, phase releases, and build in feedback loops that let the program iterate as it goes, just the way a product team would stage a launch. Each phase should build the organization's trust in the next.

6. Define success metrics before agents are built

Agree on what efficiency, quality, adoption, and business outcomes mean for this program before development starts. Efficiency might be measured as cycle time, throughput, and effort reduction; quality as accuracy, exception rates, and error recovery; adoption as utilization, override frequency, and reliance on human fallback; business outcomes as cost-to-serve, revenue impact, and service-level agreement performance.

Enterprises that scale agentic AI successfully plan for the full 100% of program effort, from the agents themselves to everything beneath the surface that makes them work. Building the readiness gate now, rather than discovering the gap mid-program, is what lets an enterprise move from piloting agentic AI to running on it.