AI adoption fails when leaders start with tools instead of operating problems.

Most of my weeks start the same way.

Someone walks into a Monday review carrying a problem they have lived with for three or four years, followed immediately by a question about which piece of software will fix it. Two years ago, the question was whether we needed a custom wrapper around a large language model. Six months ago, it was whether we should stand up a retrieval pipeline over shared folders. Lately, before anyone has even put the problem statement on the screen, the question is simpler: "Can we put an agent on this?"

My job in that room is almost always to slow the question down.

Not because I am a sceptic. I build software products and intelligence systems for a living, and we run models in live workflows every day. I slow the question down because after twenty years of working across refinery control rooms, R&D labs, consumer products, and enterprise operations, I have watched the same movie play out under half a dozen different titles. When leaders start with a tool and go hunting for a place to plug it in, they almost always end up paying twice: once for the software, and a second time to untangle the mess it makes of an already fragile process.

Technology is the last answer. It is never the first question.

The 2026 hangover: why the numbers look so brutal

For the past three years, boards and executive teams have operated under a quiet panic. Nobody wanted to be the company left behind. Budgets were unlocked in days for anything with "generative" or "autonomous" in the pitch deck, while basic operational plumbing waited in the queue.

Now that we are well into 2026, the bill for that rush has arrived, and the numbers across the industry are sobering.

According to McKinsey's latest global surveys, 88% of organisations now use AI in at least one business function. By surface metrics, adoption is near-universal. Look one layer deeper at the income statement, though, and the picture changes completely. Only 39% of those companies report any measurable impact on enterprise EBIT, and most of those attribute less than five percent of their earnings to it. The share of true high performers who are capturing significant, bottom-line financial returns sits at roughly 6%.

Other independent studies tell the same story from different angles:

• The pilot graveyard is growing, not shrinking. S&P Global Market Intelligence found that 42% of companies abandoned the majority of their AI initiatives before they ever reached production, a sharp jump from just 17% a cycle earlier. Once the initial demo applause faded, the unit economics and data headaches killed the business case.
• Scaling remains a wall. Research from both the RAND Corporation and Boston Consulting Group indicates that over 80% of enterprise AI projects fail to scale or deliver their intended operational value, roughly double the failure rate of traditional information technology rollouts. Gartner's enterprise benchmarks show only 22% of organisations successfully scaling AI initiatives across multiple business units.
• The agentic wave is hitting the same rocks. As vendors rushed to rebrand chatbots and brittle scripts as "autonomous agents," Gartner issued a blunt warning: more than 40% of agentic AI projects will be cancelled by the end of 2027. The culprit is rarely the underlying frontier model. Projects are being shut down because of runaway token and integration costs (often five to ten times the pilot estimate), unclear business value, and risk committees asking a single question that nobody in the demo room prepared for: "When this agent changes a record in production by mistake, who owns the rollback, and where is the audit trail?"

When four out of five projects stall between a flashy proof-of-concept and Tuesday afternoon reality, we do not have a model problem. The models are extraordinary. We have a diagnosis problem.

A century-old mirror: electrifying the steam factory

Whenever an executive asks me why massive spending on a breakthrough technology has not moved their productivity numbers, I ask them to look back not two years, but a hundred and twenty.

In 1990, the Stanford economic historian Paul David published a famous paper titled "The Dynamo and the Computer." He wanted to explain why decades of heavy corporate investment in mainframe and personal computers had barely registered in national productivity statistics. To answer it, he studied an earlier general-purpose technology: the electric dynamo at the turn of the twentieth century.

In the 1890s, factories ran on steam. A massive central steam engine sat in the basement, turning a heavy iron line shaft that ran the length of the building. Leather belts and pulleys carried mechanical power from that central shaft to every machine on the floor. Because mechanical energy dropped off sharply over distance, factories had to be built as cramped, multi-storey vertical boxes so machines could cluster right above and below the main engine. Materials were hauled up and down freight elevators in whatever awkward sequence the shaft layout dictated.

When electric dynamos first became commercially viable, factory owners bought them eagerly. And what did most of them do?

They tore out the central steam engine, bolted a giant electric motor onto the exact same iron line shaft, and left every belt, pulley, freight elevator, and vertical floor untouched.

For nearly twenty years, factory productivity barely moved. Electricity was cleaner than coal, sure, but work still moved at the speed of the old layout. The breakthrough only arrived in the 1920s when a new generation of industrial engineers realised they were electrifying the steam factory. They threw out the overhead shafts altogether, placed small fractional-horsepower motors directly inside each individual tool, and flattened the factory into a single-storey horizontal floor arranged in the natural sequence of manufacturing.

Look around most enterprises in 2026 and you will see the exact same mistake in digital form.

Leaders are taking a frontier reasoning model and bolting it onto a 1998 approval shaft. They are asking an AI copilot to summarise a forty-page internal memo that should never have been forty pages long, so it can pass through four layers of middle management who only sit on the distribution list because nobody has updated the delegation matrix since 2016.

If a workflow is bureaucratic, ambiguous, and starved of clean evidence, adding a language model does not modernise it. It just generates longer emails at three hundred tokens a second.

Where the alarm is not: two lessons from physical systems

Before I ever worked on software or enterprise transformation, I started my career as a chemical engineer standing in a refinery control room.

The walls of that room were lined with distributed control screens where every blinking number meant pressure, heat, flow rate, or money. When you are twenty-two and fresh out of engineering college, your instinct when a high-temperature alarm flashes on a downstream distillation column is to stare at that screen and tweak the software controller on that unit.

An experienced chief operator never touched that screen first. He would put down his tea, walk three units upstream on the schematic, and check whether a heat-exchanger bypass valve was sticking or a thermocouple was fouled with residue.

It was my first and best lesson in operating diagnosis: the problem is rarely where the alarm is. If an upstream valve is mechanically stuck, tuning the PID loop on the downstream software controller is worse than useless. The algorithm will fight the physical reality until the whole loop oscillates out of control.

A few years later, at a global beverage company's innovation centre, I learned the corollary to that rule.

A small global team of us had been given an unusual brief: invent a new kind of beverage dispenser from zero. It had to pour hot drinks in winter, cold drinks in summer, and swap modules in between, priced for emerging markets. Early on, we hit a wall on unit economics. Commercial beverage dispensers were expensive largely because accurate syrup-to-water mixing relied on precision electronic solenoid valves and flow sensors that cost roughly $500 a unit.

If you start with the tool, your question is: "Where can we buy a $300 electronic valve?"

Instead, we stepped back and asked what the physical operating problem actually was. The machine did not need electronics for the sake of electronics; it needed to hold a constant volumetric mixing ratio between two fluids when line pressure varied.

That is a fluid-dynamics problem before it is an electronics problem.

Going back to Bernoulli's equation, mathematical modelling, and computational fluid dynamics, I developed the fluid-dynamics basis for a Venturi mixing architecture. As water accelerated through a precisely shaped constriction throat, the pressure drop drew in syrup at a self-regulating ratio dictated by geometry rather than circuit boards. It replaced an approximately $500 electronic assembly with an approximately $5 piece of moulded geometry. That work led to five granted patents where I was the first-named inventor, and we took the dispenser through to successful pilots.

I think about that $500 valve at least twice a week when reviewing AI proposals today.

Half the requests that land on an enterprise AI team's backlog are "$500 valve" problems in disguise. A business unit asks for a multi-agent orchestration layer to reconcile weekly sales numbers against warehouse dispatch logs because the two reports never match. You can spend six months and $150,000 in engineering time building an LLM agent that fuzzy-matches product names across two messy spreadsheets. Or you can walk upstream, discover that Sales and Logistics have been generating separate item codes since a merger four years ago, lock a single master table in the database, and solve the problem permanently with twenty lines of SQL and a one-page policy sign-off.

Bernoulli is cheaper than tokens. So is a foreign key.

How days became minutes: anatomy of a real turnaround

What does it look like when you actually start with the operating problem?

Not long ago, we looked at how institutional approvals and audit checks were running across a large group of schools, higher-education institutions, and the operations around them. Files for fee adjustments, vendor clearances, and audit verifications were taking days, and sometimes over a week, to clear. Paperwork piled up, status checks happened over phone calls, and reviewers spent hours cross-checking attachments.

Everyone involved had the same initial diagnosis: "Our legacy software is clunky. Give us an AI tool that reads the uploaded files and approves them."

Had we listened to that request literally, we would have built a disaster.

Before writing a single line of model code, we pulled a sample of real approval files and traced their journey desk by desk, hour by hour. Within forty-eight hours, it was obvious that software speed had almost nothing to do with why files were taking five days. The delay lived in three very human places:

1. Ambiguous policy thresholds. For a whole middle band of routine requests, the written policy did not clearly state whether a local head could sign off or whether the file had to travel to the central office. Out of caution, people forwarded everything upward. Three senior people were reviewing the same routine request because nobody wanted to be the one who signed alone.
2. Broken intake evidence. Roughly half the time a file stalled for three days, nobody was even working on it. It was sitting in a "pending query" state because the person submitting the request had attached an invoice without a purchase order, or a concession request without the supporting family income certificate. The system allowed incomplete packets through the front door, guaranteeing a multi-day ping-pong match later.
3. Blind reviewing. When an auditor finally opened a packet, they had to manually hunt through six PDFs to verify four basic facts: did the numbers match the policy table, was the budget line open, was the prior history clean, and were all signatures present?

Notice what happens if you drop a generative AI agent onto that unreformed process. The agent tries to infer policy rules that humans have not agreed on, guesses at missing attachments, and produces confident-sounding summaries over incomplete evidence. In a financial and audit workflow, "mostly right" is another word for broken.

So we inverted the sequence. We spent the first seventy percent of our energy on the human and policy operating system:

• First, we rewrote the decision rights. We sat with leadership and finance to lock crisp, unambiguous thresholds. Anything inside policy band A stayed local with automated logging; only genuine exceptions escalated centrally. That single policy change deleted a huge slice of the queue overnight without a single GPU cycle.
• Second, we hardened the front door. We rebuilt the intake workflow so a request simply could not be submitted until the required evidence trail for that specific category was complete and structured. No more four-day pauses waiting for a missing page.
• Third, and only third, we placed AI inside the loop where it could check evidence rather than guess at it. When a file entered the system, the model extracted the structured fields from the supporting documents, cross-checked every figure against the locked policy rules and historical ledger, and assembled a one-screen verification brief for the human decision-maker. It did not replace accountability; it removed the scavenger hunt.

Days of waiting became minutes.

When people see the live system today, they naturally point to the AI layer as the magic. Anyone who was in the room during the build knows the truth: the model only works because we cleaned the pipes before we turned on the pump.

The 10–20–70 rule (and why most budgets are upside down)

Boston Consulting Group has a useful shorthand for this that matches every successful rollout I have led. They call it the 10–20–70 rule.

In any enterprise AI transformation that actually sticks and returns money to the P&L:

• 10% of the effort is the algorithm or model selection. In 2026, foundation models are abundant, capable, and increasingly commoditised. Swapping one frontier model for another rarely turns a failing project into a winner.
• 20% of the effort is the technology and data harness: clean pipelines, retrieval architecture, latency engineering, role-based access, evaluation suites, and audit logging.
• 70% of the effort is people, policy, and operating process: redesigning how work flows across desks, clarifying who holds decision authority, changing incentives so teams trust and verify the output, and retiring the old shadow spreadsheets so people do not run two systems in parallel.

Why do 80% of projects fail to scale? Because most organisations allocate their time, attention, and executive sponsorship in the exact opposite ratio. They spend 70% of their energy debating model benchmarks and watching vendor demos, 20% wiring up a quick API prototype, and 10% on the Friday before launch sending an email telling staff to use the new button.

A six-gate diagnostic before you write a prompt

During my years governing a national beverage innovation portfolio, I learned to love Stage-Gate discipline. Innovation is not a mood; it is a funnel with teeth. Ideas move through gates, and each gate asks one unsentimental question: does this idea still deserve the next rupee and the next month of engineering time?

If you are leading a business unit, a technology org, or a company in 2026, you do not need an "AI strategy" document bound in a slide deck. You need a set of gates that every proposed use case must clear before anyone spins up a cluster.

Here are the six gates I use:

Gate 01: Name the bottleneck without saying "AI"

Require the sponsor to write down the operating problem in three sentences without using the words AI, LLM, copilot, agent, machine learning, or automation. What specific decision is too slow? Which handoff has a twelve percent error rate? Where are customers or internal teams waiting four days for an answer that should take ten minutes? If the team cannot quantify the friction on the current clock, stop at Gate 01. You are looking at a solution in search of a headline.

Gate 02: Walk three real cases by hand and clean the policy

Before touching software, pick three actual transactions from last month (one clean, one delayed, and one that went wrong) and walk them end-to-end with the people who actually do the work. Not their VPs; the people who type into the screens. Ask why each signature exists. If three people sign a form because a ten-year-old circular was poorly worded, rewrite the circular. Delete every step that only exists because of institutional habit. Never pay an engineer to automate a step that should be abolished.

Gate 03: Audit the evidence trail at the door

Ask a simple question: if you locked a smart, newly hired human analyst in a room with only the data this model will receive, could they make the right call every time? Usually, the honest answer is no, because half the context lives in WhatsApp threads, phone calls, or unattached PDFs. Fix the intake contract first. Make sure the evidence required to make the decision is captured cleanly at the start of the workflow. Models are pattern engines, not clairvoyants.

Gate 04: Reach for the simplest mechanism that works

Establish a strict hierarchy of complexity in your engineering culture:

1. Can we solve this by deleting a policy step?
2. Can we solve it with a database constraint or twenty lines of deterministic code?
3. Can we solve it with a fast, narrow classifier or regression model that costs fractions of a paisa per call, telling an urgent ticket from a routine one, or a real sales lead from noise?
4. Does it genuinely require a generative language model over unstructured text, grounded in retrieval over our own verified documents?
5. Does it truly require an autonomous multi-step agent with tool-calling privileges?

When AI is doing its best work inside a product, nobody even calls it AI. It simply routes the urgent thing to the top of the screen and pre-fills the verified facts.

Gate 05: Build the harness before you trust the horse

A raw model in a Jupyter notebook is a science project. A model in an enterprise is only as good as the harness around it. Before any pilot touches real users, define the guardrails: What is the confidence threshold below which the model must hand off to a human? How is every input, retrieved source, and model output logged for audit? What happens when a user tries to bypass a policy rule through the prompt? And where is the circuit breaker if API latency or token spend spikes on a Monday morning?

Gate 06: Measure the operating clock, not vanity usage

Ban vanity metrics from your board pack. "Number of employees with copilot seats," "total prompts run this month," and "self-reported hours saved" are theatre. If a tool is genuinely working, it will show up on the operating clock within ninety days: cycle time from submission to closure (days down to minutes), first-pass audit accuracy, cost per completed transaction, or revenue conversion per lead. And ask one question six months after launch: did this system leave our team more capable and better informed, or did it just create a new black-box dependency that nobody on the floor understands?

Building what lasts

Every few years, the technology industry invents a new vocabulary designed to make experienced leaders feel that the old rules of operations no longer apply. In the late nineties, it was ERP. In the early 2010s, it was big data lakes. Today, it is reasoning models and agent swarms.

The tools genuinely are stranger and more powerful now. They can read messy handwriting, synthesise thousands of pages of technical specifications, and draft code in seconds. Used well, they compress weeks of drudgery into an afternoon.

But the physics of an organisation has not changed since the steam engine, and it has not changed since that refinery control room twenty years ago. Work still flows through people, policies, incentives, and evidence. When those four things are tangled, the smartest model in the world will only tangle them faster.

So the next time someone walks into your Monday review and asks where you are deploying agents this quarter, do them and your P&L a favour. Close the laptop halfway, pull a marker to the whiteboard, and ask a much older question:

"Show me how a single file moves from the front door to the final sign-off today, and show me where it waits."

Understand the system. Find where it really breaks. Then build what lasts.

Automating a broken workflow does not give you transformation. It only gets you to the wrong answer faster, at a higher monthly run rate.