By Manoj Chugh
Of late, many friends have expressed deep anguish at not being able to convince their boards to go full hog and embrace the new Religion of AI ,at an Enterprise level. Being on several boards, I can well understand the scepticism of the boards. Industry estimates now put a number to that anxiety. More than 40 percent of agentic AI projects will bite the dust before the end of 2027. The reasons cited are not a State Secret.
Unclear business value, inadequate risk controls and escalating costs ( tokenomics) are amongst the top three. Underneath these is a pattern, a lot of what gets marketed as an “agent” today is really an ordinary chatbot or a piece of robotic process automation wearing a new label. History has taught us that labels often sell better than the underlying substance. Of the many vendors now claiming agentic capability, a comparatively small number actually meet the definition.
What is striking about this list of three reasons is that quite unlike in the past, when complexity of technology has been often blamed for lack of adoption, this time, nobody is saying that the model isn’t good enough. Enterprises are not cancelling agentic AI projects because the technology has failed to perform.
They are getting distraught because the outcomes from the projects have not been tightly defined, nobody can actually commit with certainty what it would cost at scale, and nobody knows how to trust or verify what the agent will doing and take ownership for the behaviour. This challenge is only getting enhanced with ever frequent reports of “jail breaks” by AI agents. Honestly , none of these is a model problem. All of it is a problem the enterprise created for itself the moment it treated a working demo as a finished plan.
Having spent enough time inside these rollouts, there is method we have observed about the order in which these three problems can get solved, with the addition of a fourth. Solving the first three without a way to know whether the organisation is making progress is also a kind of a failure.
Finding the real barrier, architecting the layer that is missing, controlling the economics and then evolving into the next stage of readiness, are the four key ingredients of the recipe. Not only the ingredients, but the order in which they are “ applied,” are the key determinants of success.
Let us start with Find, because this is where most of that “unclear business value” actually originates. Ask five people inside the same enterprise why their agentic pilot stalled and you will get different, all partially true answers- the data was not ready, the workflow did not map cleanly, nobody could agree with what success looked like, the pilot was scoped to impress a steering committee rather than solve an actual bottleneck.
Multiple symptoms of one underlying failure, nobody found the real barrier before building around an assumed one.
In our experience, five specific barriers account for most of what goes wrong:
1. Agents get deployed as disconnected point tools with no shared routing between them.
2. They operate without real business context, so the moment a question strays outside a scripted lane, they improvise badly.
3. They’re wired tightly to one cloud, one model, one framework, which quietly turns today’s convenient choice into tomorrow’s constraint.
4. Nobody is tracking spend at the level of an individual workflow, so costs that looked trivial in the pilot become a board-level surprise in production.
5. There is no audit trail, which means legal and compliance have no way to sign off on a decision they cannot inspect. Nervousness around what shows up in the data has inadequate risk controls.
The objection we hear is that naming five barriers before building anything sounds like analysis -paralysis dressed up as rigor. It is not. A demo is specifically engineered not to encounter any of these five, because it runs on clean data, inside one workflow, with no real cost pressure. Production removes all three comforts at once. Finding the barrier before it is expensive is not caution for its own sake- it is the difference between fixing a problem and discovering a new one every time you try to scale.
Let us move to the second one- Architect. It corrects a habit we see in nearly every enterprise we work with, over-investing at the bottom of the AI stack and under-investing in the middle of it. Compute, models, and agent frameworks are close to commodity purchases now. Any organisation with a budget can buy them, and most do. What almost nobody buys, because almost nobody thinks to, is the layer that decides which agent handles which task, tracks where a multi-step process actually stands, and enforces the rules an agent is allowed to act within.
That coordination layer sits in the middle of a five-layer stack- infrastructure, model, agent framework, coordination, and the applications people actually see. Enterprises routinely build every layer except that one, then wonder why the whole system behaves like five separate tools bolted together rather than one thing that works. It behaves that way because, architecturally, that’s exactly what it is. The natural pushback is that building a coordination layer for a first pilot is over-engineering – you don’t need a highway system for one car.
Fair, and also not the argument. The fix isn’t to architect the whole stack on day one, it is to build the coordination layer for the one workflow actually running, so the second and third agents added later don’t each need to be bolted on separately. Enterprises that skip this step do not save the work, they pay for it later, all at once, when three uncoordinated agents finally need to talk to each other and nothing was built to let them.
The third move, Control, is where that “escalating costs” figure lives, and it is the most measurable of the four. Training a model is a one-time cost. Running it in production is not and for most enterprises the ongoing inference dominates total AI spend.
One documented account from a financial-services deployment put monthly inference costs above Rupees. Two crores, with more than 70 percent of the traffic being routine queries that never needed a frontier model in the first place. This is a common pattern that shows up almost everywhere, when one gets down to measuring it. The fixes are well understood, even if most enterprises use only one at a time instead of all five together. Route simple tasks to smaller, cheaper models and save frontier capability for genuinely complex reasoning.
Published benchmarks put the savings anywhere from 40 to 70 percent, and one widely cited industry study found routing can cut inference cost by as much as 85 percent under the right conditions.
Try a few simple techniques:
-Cache repeated outputs instead of regenerating them.
-Track spend by workflow and by agent, since cost nobody is measuring is cost nobody can manage.
– Trim bloated prompts, which compound meaningfully at volume.
– Batch anything that doesn’t need an instant answer. Major model providers typically offer roughly a 50 percent discount on batched, non-real-time requests, which is about as close to free money as enterprise software gets.
An objection that we often hear is that that obsessing over cost early kills the experimentation a young AI program needs. The bottom line is that visibility is not the same as austerity. Measuring what a workflow costs doesn’t mean refusing to spend on it. It means the decision to spend gets made on purpose, by someone who can see the number, instead of discovered by finance eight months later!
The last move, Evolve, is the one enterprises want to skip to and the one that most depends on the other three having actually happened.
Organisational readiness for agentic AI tends to move through four recognizable stages, whether or not anyone names them- Pilots and proofs of concept that teach plenty, but ship nothing real, agents doing real work inside one process. As numbers start to move we get multiple agents coordinating across departments on shared context. Then we start to look at the costs
Finally, as we move along, agents improve without a human re-approving every step. Humans set the boundaries rather than policing every action inside them.
The obvious risk with any maturity model is that it becomes a vanity roadmap, a slide that makes leadership feel like they are progressing whether or not anything underneath has actually changed. The fourth initiative does not mean anything on it’s own, stand alone. It is what the first three, done honestly, add up to.
The three reasons most commonly cited for disappointment with AI Projects map almost exactly onto the first three of the four moves.
This is not a coincidence – it is the pattern that led us to this sequence in the first place. Unclear business value is a Find problem. Escalating costs is a Control problem. Inadequate risk controls sits at the intersection of Find and Architect.
You cannot govern a decision you never diagnosed, routed through a system nobody coordinated. An enterprise that jumps straight to architecture without first finding its actual barrier builds coordination for a problem it doesn’t have. One that tries to control costs before the architecture exists is optimizing spend on a system that was never going to hold together anyway. And no enterprise evolves its way to maturity while its underlying architecture is still leaking money with no one watching.
That’s the honest answer to that 40 percent figure, and to every version of it that’s come before. It was never really about whether the model was ready. It was about whether the enterprise did the work, before deciding the technology was the problem. And that is why the FACE Maturity Model was created- to help sequence the Right Order!
( Manoj Chugh is Chairman of the boutique Advisory Firm- Manoj Chugh Advisory LLP)