All insights

False Summits: Why Enterprise AI Keeps Looking Finished

A practitioner's map of the six milestones that feel like the finish line, why the best teams still stall, and the three disciplines that actually reach production.

Every enterprise AI program I walk into believes it is almost finished. Most are halfway up the mountain, standing on a ridge that looks exactly like the top.

Climbers have a name for that: the false summit. You crest what is plainly the peak, and the real one appears behind it, higher, colder, and further off than anything you have climbed. Enterprise AI is a mountain made almost entirely of these, and the cost of mistaking one for the top is measured in quarters, not days. A decade ago there were a few hundred AI companies; today there are tens of thousands, and every one of them is standing on one of these ridges, telling you it is the top.

Illustration from False Summits: Why Enterprise AI Keeps Looking Finished

Two ridges come before the real climb even starts, and nearly everyone clears them and calls it progress.

The first is the demo. An agent answers a hard question against a clean, hand-picked set of sources, in a sandbox, in front of the executive committee. It is convincing precisely because everything that makes the enterprise hard has been removed: the data is tidy, the questions are the ones the demo was built for, and nobody is asking what happens on Monday when a thousand people use it. A demo proves something is possible. It does not prove you can deliver it.

The second is enterprise chat. You switch on an assistant for everyone, wire it to email and documents, and the adoption charts climb. The gains are real, but they are small, and they show up in the employee’s day, not on the income statement. I have started calling this corporate wellness: a decent thing to offer, and people feel supported, but it was never going to change the financials. Set a usage target like “use the assistant four times a day”, and people will ask about the weather to hit the number.

Both ridges make the same mistake, and it is the one hiding under every false summit higher up: they confuse the how for the why. Across the 477 of these conversations my team has sat in since January, everyone wants the same thing, and it is not AI. They want operational leverage, the ability to do more with what they have. AI is the how; operational leverage is the why.

It helps to be precise about the work AI should actually do. The sweet spot is high complexity, low judgment tasks. High complexity, because if the task were simple you would have automated it years ago with if-this-then-that rules. Low judgment, because you do not want a model deciding which drug to prescribe or whether to approve a mortgage. You want it to do the gathering and cross-checking, the swivel-chair work, and hand a complete picture to the expert who makes the call. Keep that test in mind and the real false summits explain themselves.

Above the tree line, the climb gets serious. These are the four that cost real years.

Summit one: ten times the code

The first real false summit is AI-assisted software development, and it is seductive because the gain is visible: the tools work, and engineers produce dramatically more code. The mistake is reading code velocity as product velocity.

Across the teams I see, 10x the code is not turning into 10x the product, or even a noticeably faster roadmap. One CIO told me an AI agent had rebuilt the same component 76 times in a month, a component that already existed, leaving him with 76 versions to maintain and a strong wish to put the genie back in the bottle. He has since taken the tools off his developers, not because they do not work, but because the old way of specifying, reviewing, and shipping software cannot absorb that volume. Writing the code was never the bottleneck. The real constraints were deciding what to build, checking it, and integrating it safely, and those are the parts the tools do not yet speed up.

Code was never the constraint. Until the process around it is redesigned, more code just means more to review.

Summit two: centralizing the data

Once teams build agents that act rather than answer, they hit the real state of enterprise data: scattered across dozens of systems, structured and unstructured, some of it true, some stale, much of it contradictory. The instinct is the one the industry reaches for every cycle: centralize. Get everything into one place so the agent has one surface instead of forty. Whole programs are commissioned on that theory, often with a multi-year price tag.

Then you finish the migration and find that location was never the hard part. The agent can reach everything and still does not know what anything means. Roughly a third of the meaning is clear. Another third is ambiguous: is the “customer” in one system the same as the “customer” in another? The final third was never written down at all; it lives in the heads of people who have done the job for fifteen years. Moving data recovers none of that. The first third is software, the second needs experts resolving cases one at a time, and the third can only be learned by watching how the work is actually done.

There is a second cost that rarely gets priced. When you centralize, you hand your hardest-won knowledge to whichever platform you migrated into. For a one-off report, fine. For the understanding that makes your business run, it is worth asking whether you want it living inside a single vendor.

The battle is over meaning, not location. Pay for understanding before you pay for migration.

Summit three: the first dozen agents

This is the summit that fools the most capable teams, because by the time they reach it they have done everything right and have the scars to prove it. I had dinner recently with senior AI leads from some of the largest financial institutions in the world. The pattern around the table was remarkably consistent: a dozen, maybe two dozen, meaningful agentic experiences in production. Built by dedicated teams that started around fifteen people and grew to thirty-five over the twelve months it took.

Now do the arithmetic out loud, which almost nobody does. A win is not a dozen agents; inside a large enterprise the real surface area is thousands, maybe tens of thousands, of these workflows. If the first dozen took a year and a team of thirty-five, the current approach gets you to full scale somewhere around 2035. Every leader I put that number to goes quiet, because they have done the same math privately and kept it to themselves.

The reason sits in how those first agents were built. Getting an answer at all is the hard 30%, the context work, wired by hand for each agent. Earning the right to trust the answer is the other 70%: the evaluations and checks, the machinery that catches a mistake before a customer does. Almost all of it is hand-built, per agent. The thirteenth agent costs roughly what the first one cost. Nothing accumulates. That is the defining feature of a false summit: the effort does not turn into height.

Track the cost of your next agent, not the count of your last ten. A flat cost curve at agent twelve is your next five years.

Summit four: the bill

The last summit arrives as a reward for success. One bank built an internal assistant for its developers and tested it on five small systems, where it was accurate and cheap. Then they pointed it at three dozen real ones. The answers held up; the cost did not. Queries that mattered now ran past two dollars each across tens of thousands of engineers. The options were all bad: move everything into a warehouse, pay the token bill and hope, or rebuild the data a third time as a graph. None of those is a strategy.

This is the part nobody prices in during the pilot. Metered tokens look harmless at prototype volumes. At enterprise scale, with agents making dozens or hundreds of model calls per task, the bill starts to behave like a cloud bill: opaque until you instrument it, volatile until you govern it, and politically radioactive once it shows up in operating expense. CFOs have seen this film before, when predictable capital spend turned into unpredictable cloud spend, and they remember the ending. Two things make it worse. The same task that costs ten dollars on a frontier model is often a fifty-cent task on a smaller one, but only if your setup can route between models at all. And the “best” model keeps changing, so anything hardwired to a single provider is a depreciating asset.

What matters is cost per finished piece of work at a set quality, and the ability to swap the model underneath it in weeks, not quarters.

The actual mountain

So what does the real summit look like? It is a system that actually holds up in real-world conditions: answers it can trust and stand behind, on the messy data it already has, fast and affordable across the whole enterprise. Every false summit falls short of that in a different way. The coding wave produced far more code, but not more finished products. Centralizing the data put everything in one place, but the agent still could not tell what any of it meant. The first hand-built agents worked, but each new one cost about as much as the last: the cost never fell and nothing carried over, so the approach could never scale. And the moment real usage arrived, the token bill made it impossible to sustain.

Underneath all of them is one shift most enterprises have not absorbed: this is the first major wave of technology built on probabilistic foundations. Every previous system gave the same answer to the same question every time. A language model does not. Ask it the same question five times and you can get five different answers, each delivered with full confidence. Everything an enterprise means by “production” was defined in a deterministic world: auditability, repeatability, accountability. Crossing that gap is the whole climb.

What the crossing demands turns out to be specific, and it is not more clever agents. It is three disciplines.

The first is a living data foundation, built where the data already sits. Not another migration into a warehouse, but software that reads every source in place, whatever the system or data model, structured and unstructured alike. It works out which entities are which, fills in the missing context, and keeps re-resolving as schemas, joins, and meaning shift underneath it. A static catalog is stale the moment it is finished, because the business does not hold still. A foundation that re-resolves against live sources and real workflows is the thing centralizing was reaching for and never caught.

The second is context and guardrails built by software, not by hand. The 30% that surfaces an answer and the 70% that earns the right to trust it: the evaluations, the judges, the checks, generated and enforced across a whole population of agents at once, with evaluation kept permanently in the loop. Crafting one agent by hand is tractable. Governing thousands of them, as models and prompts drift beneath you, is not. Not by people, not ever. It is the only thing that makes effort accumulate into altitude instead of starting again from zero at agent thirteen.

The third is the move from exploration to dependable execution. Let an agent reason a task out once, in full; grade that path; and when it is proven, promote it to plain code that runs the same way every time, with the model verifying the result rather than rediscovering it. The same question stops returning different answers. The cost stops rising every time you ask. Proven work hardens into infrastructure, which is exactly what a regulated business means by production.

Between them, those three clear the false summits that cost companies years: the meaning, the hand-built dozen, and the bill. None of it looks like building impressive individual agents. It looks like building the thing that builds them: the shared understanding of the business, the machinery that checks the work, and the path from probabilistic exploration to deterministic execution. The agents are the easy part. The discipline underneath is the climb, and it is where the advantage that compounds for a decade actually lives.

Two principles hold it together. Start with the AI working in the background while a person signs off on every result, and let it earn more autonomy only on evidence, not enthusiasm. And design accountability in from the first day, because when an AI-assisted decision goes wrong, “the system told me” is not an answer.

None of this is a counsel of despair. The mountain is climbable, and the teams that climb it will hold an advantage that compounds for years. But the route matters more than the enthusiasm. So one question to carry into your next AI review: are we higher than we were last quarter, or are we standing on another ridge? The teams that ask it early save themselves years.