When a company builds something with AI, it is really building two things at once. The first is the foundation: its data, its permissions, the connections between its systems and the rules of how its business runs. The second is scaffolding: the prompts, patches and workarounds that make today’s models good enough to use. Every new model release makes the foundation more valuable and makes some of the scaffolding unnecessary. I call the boundary between the two the depreciation line. Companies that never draw it fund both layers as one, and end up paying for scaffolding as if it were built to last.

The advice everyone starts with

For the past two years, companies starting with AI have heard two pieces of advice. Large companies are told to start small: run a pilot, pick a contained workflow, prove value, then expand. AI-native builders say something bolder: build for fast obsolescence, and be ready to throw code away whenever a better model arrives.

On the ground, though, the conversations I have with operators end somewhere else. Most of them have already seen the technology work, usually in a demo they ran themselves. What they want to know is whether the thing they are about to build will still be worth owning eighteen months from now.

Neither piece of advice answers that. A pilot shows whether a tool works today. It says nothing about whether the thing you are about to harden deserves hardening, and hardening is where the money goes. Throwing code away is easy for a startup. For a company with customers on the system, it is a luxury, and that gap is what this piece is about.

The line

Side by side, the two layers look like this.

One question sorts most pieces. If the next model did this task perfectly, would you still need this? If yes, it is foundation. If no, it is scaffolding.

If you build agents, a third word will already be on your mind: the harness, the runtime around a model that runs its loop, calls its tools, manages its context and enforces its permissions. Foundation and scaffolding describe why a piece of work exists. A harness describes what a piece of software does, and it contains both. The parts of a harness that connect the model to your systems, control what it is allowed to touch and record what it did belong in the first column. The parts that exist because today’s models lose track of long tasks, run out of context or need a second pass to get things right belong in the second. Treating the whole harness as one asset is the same mistake in a smaller box.

The rule that follows is simple. Build the first column to last. Build the second column to work, and only to work. Every hour spent making the scaffolding elegant is an hour spent hardening the part most likely to be deleted.

That changes the investment case as well as the architecture. Instead of carrying one return figure over three years, you carry two. Say a piece of scaffolding only pays back over thirty months, and you expect a model release to absorb it in twelve. You already have your answer, and no pilot will change it.

Why this is new

A company buying a workflow tool in 2018 could assume the capability it was paying for would still be scarce three years later. I built on that assumption for most of my career, and it held. It has stopped holding.

Nicolas Bustamante, founder of the AI research company Fintool, described the mechanism plainly in an essay first published in October 2025, “LLMs Eat Scaffolding for Breakfast.” Miss a single capability announcement from one of the major labs, he writes, and months of work can become obsolete. He names the casualties: vector databases, LLM frameworks, dedicated prompt engineering teams. Each was built in good faith to cover something models could not yet do, and each was absorbed once they could. He is just as direct about why teams hold on, from sunk cost to organisational inertia.

The same thing has happened inside everyday practice. Two years ago, teams building with these models kept libraries of carefully tuned prompts. They broke work into small steps and had a person check each one before the next began. They wrote extra code to catch output the model got wrong. Much of that has been absorbed. Today’s agents take a goal rather than a script, check their own steps along the way, and write much of their own test code, and a person reviews the result rather than every step. Testing shows where the line falls. The effort of writing tests turned out to be scaffolding, because agents now do most of it. The tests themselves, which spell out how the business is supposed to behave, are foundation. They matter more now, because agents write code against them. Run each piece through the question from earlier and it sorts itself.

The economics underneath are moving even faster. In September 2026 the research group Epoch AI estimated that the cost of reaching a fixed level of AI performance has fallen by about 47% every quarter since 2023, which works out to roughly 13 times cheaper each year. By their comparison, that is faster than computing, DNA sequencing or batteries ever got cheaper. Their own caveat is that benchmark scores are not the same as useful work. Even so, a capability that is expensive enough to justify custom scaffolding today is likely to be cheap, or built into the model itself, within a year or two.

Put together, this leaves companies with customers in an awkward position. What seems to be happening is that they make one of two mistakes. Some approve the whole build on a single business case, and end up paying to harden scaffolding that the next model makes unnecessary. Others cannot get that single business case past finance, because nobody can say how long the thing will last, so the project stalls in pilot. Both mistakes come from treating two kinds of investment as one.

Who this applies to

The problem is sharpest for a particular kind of company, and it is tempting to describe them by size. Size is the wrong way to sort them. What matters is whether a company can afford to throw code away, and three conditions make that hard.

The first is revenue to protect. Customers use the system today, under contract, and their expectations do not pause for a rebuild. The second is that technology supports the business rather than being the business. Customers pay for a service, and software is how it gets delivered. The third is a fixed technology budget in which AI is one line among many, competing with security, compliance and a roadmap already promised.

A 40,000-person enterprise meets all three as often as a 200-person services firm does, and so does almost any business unit inside a large company. That is why a big budget protects less than people assume. More money does not help when nobody can say how long the thing being funded will be needed.

To be fair, two kinds of company sit outside this problem. The first is the AI-native company, with no installed base and no contracts to honour. For them, Bustamante’s own advice, to build for fast obsolescence, celebrate deleting code and pivot in days, is exactly right. He sees this as where startups beat big companies, which he says are “late by at least two paradigms.” From inside a company with customers, much of that lateness is the cost of keeping those customers served.

The second is the company whose advantage has nothing to do with software. A maker of grid-scale energy storage is protected by its cell supply agreements, certifications, construction partnerships and installed base. AI sharpens its forecasting and speeds up its paperwork, and touches none of that. When a company like that explores AI without making big bets, it is reading its own moat correctly.

Drawing the line

Running through all of this is a shared belief that an AI investment is one thing, to be approved or turned down as a whole. This is where I differ. Drawing the line splits the decision in two. You decide, in advance and on the record, which parts you are willing to delete later, and you fund each part on its own terms. It is the version of building for obsolescence that a company with revenue can actually carry out.

In the platform rebuilds I have been part of, stopping was never an option. The old system had to keep serving customers every week of the migration, so nothing could be deleted until its replacement was already carrying the load. That is the normal condition of running software, and “delete it and pivot in days” does not describe it.

What survived those rebuilds was rarely the clever part. It was the data model, the permissions, the integrations and the audit trail: the unglamorous first column. AI is running the same pattern, only faster, which is why it pays to know in advance which column each piece belongs to.

Where the line goes from here

Two parts of this are still open, and they point the same way.

The first is how long scaffolding lasts. Nobody knows the right useful life for the second column, and I would be wary of anyone selling a number. Twelve months is a guess. So is eighteen.

The second is that the line itself moves. Some of what sits in the first column today, integration code especially, is exactly what better agents are learning to write. The table is a snapshot of today.

Both lead to the same answer. The line has to be redrawn on a fixed schedule rather than drawn once and defended. With the cost of a given capability roughly halving every quarter, a yearly review is too slow, which is awkward when budgets are still set once a year. The alternative is already visible. Gartner forecasts that more than 40% of agentic AI projects will be cancelled by the end of 2027, because of rising costs, unclear business value or weak risk controls. Read against everything above, much of that looks like the cost of never drawing the line at all.

What to do about it

For anyone approving AI spend, three things follow.

1. Split every AI investment into two lines before you approve it. Foundation on one, scaffolding on the other, harness included. If a team cannot tell you which is which, that is your first finding.

2. Give the scaffolding an expiry date, and make it pay back before then. Write down the useful life you are assuming. If a piece only pays back after a model is likely to absorb it, build a cheaper version or skip it.

3. Redraw the line on a schedule, and keep score. Revisit it every quarter, or with every major model release. Record what got absorbed and how long it lasted. Almost nobody shares this across companies, so every organisation pays the same tuition privately. Your own record is the closest thing to an answer you will have.

I think that is where this settles. The companies that do well with AI will still throw away scaffolding, often and at real cost. The difference is that they will have decided in advance which parts were scaffolding, priced them that way, and kept their money in the foundation that every new model makes more valuable.

Sources

• Nicolas Bustamante, “LLMs Eat Scaffolding for Breakfast” (October 2025)

• Epoch AI, “The plunging price of thought” (September 2026)

• Gartner, “Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027” (June 2025)

For two years, AI agents shopping on a customer’s behalf lived in strategy decks. In September they became a product. Meta’s Muse reached the top of Apple’s free app chart ten days after launch and can book, buy and check out across the web. Three weeks later OpenAI launched Dots. Most coverage asks whether consumers will trust these agents. I think the businesses on the other end have more at stake, and many of them are still waiting to see where the market goes.

Waiting is now a decision too. The companies that are blocking or partnering on purpose are learning how this works. The ones waiting will be drawn into a game whose rules they did not write.

What changed

Agents that act for shoppers are not a new idea. What changed in the last few weeks is that three conditions arrived at once.

Agents stopped asking permission. OpenAI’s in-chat checkout, launched in September 2025, only covered merchants that signed up and integrated, so a business could ignore it. Muse works differently. Where a service has no official connection, Meta says the agent can use it through a browser the way you would. Your business is in the game whether or not you joined, which is why Amazon had to block Muse to stay out.

Distribution arrived. These agents now ship inside products people already use every day. Muse works inside WhatsApp and is free to start. Dots lives inside ChatGPT, which OpenAI says has 900 million weekly users.

Money and markets moved. Mark Zuckerberg has said Meta will take a small fee on Muse transactions. Once Muse showed it could book travel, investors sold off travel stocks within days. Businesses started taking public positions, some blocking and some signing on.

None of this means agents have already won. When Walmart sold through ChatGPT’s in-chat checkout, purchases converted at about a third of the rate of its own site, Walmart told Wired. The threat is real, the rules are still being written, and that is the opening.

Why big tech is pushing

Free chat is hard to make money from. OpenAI reported about 50 million paying subscribers against 900 million weekly users, so roughly one user in eighteen pays. An agent that books or buys creates a transaction, and a transaction can carry a fee. OpenAI’s first attempt stalled and it pulled back to product discovery. Meta is now trying again at a larger scale.

For big tech, this is the first consumer AI model that can earn from every user. For many of the businesses those users buy from, the incentives run the other way.

Attention versus value

My read is that the impact splits along one line.

An agent goes to the item, compares on what it was told to care about, and leaves. When OpenAI launched shopping in ChatGPT, it said it ranked merchants on availability, price, quality and whether the merchant is the primary seller. Placement and persuasion were not on the list. Arun Sundaram of CFRA said businesses that depend on consumer inertia, meaning customers who buy out of habit, are the most exposed when agents make comparing easy.

Many companies sit on both sides of this picture. Amazon is one of the strongest value businesses in the world and also runs a large advertising business. For companies like that, the split runs through the middle of the company.

What an agent needs, and the three doors

To finish a job, an agent needs three things from a business. It needs a way in, through an official connection or a browser using the customer’s password. It needs a name tag, so the business knows it is an agent and whose agent it is. And it needs a wallet the store accepts. Every choice a business makes comes down to which of these it grants, to which agents, on what terms.

Who is writing the rules

Four companies show what being in the game looks like.

Amazon blocked on purpose. It asked Meta to leave Amazon out of Muse, then blocked the agent. It gave three reasons: Meta never told Amazon that Muse would shop there, the agent does not identify itself, and it appears to capture and store customer credentials. Analysts also pointed to a business reason, since an agent that clicks buy skips the browsing that retail ads are sold against. Amazon did not partner, but its demand that agents identify themselves could become a standard others follow.

Shopify opened the door for its merchants. On September 21, the day after Amazon’s block, Shopify CEO Tobi Lütke announced a partnership with Muse for agentic checkout with Shop Pay on all Shopify stores. It is the opposite of what Amazon objected to. The agent finds products through Shopify’s catalog and pays through Shop Pay, without logging in as the customer. Shopify’s shares rose about 7% that day and again the next. There is a catch for its merchants. Shopify had already added Meta as an AI channel on September 8, the day Muse launched, with product sharing and direct checkout on by default for eligible stores. Switching off catalog access does not stop a store’s public pages from being crawled. Many merchants entered this game through a decision their platform made for them.

Walmart played and learned. It sold through ChatGPT’s checkout and measured the result: a third of its own site’s conversion rate. OpenAI later let merchants keep their own checkout. My read is that data from players like Walmart helped change those rules. Walmart is now a Muse partner, though NBC News found its site still blocking Muse in tests, so even players are still working it out.

Expedia joined and paid for it. It announced its Muse partnership on September 22, and its shares fell about 7% the next day. Being in the game is no guarantee. But Expedia is learning on live traffic while its competitors guess.

None of these four has this figured out. All four are learning, and their choices are shaping the terms everyone else will get.

Where this is heading

This part is my own synthesis. If some businesses open the door and others close it, agents will route around the closed ones, and what an agent can reach becomes what its user sees. The largest destinations can afford to block, because people will still come to them directly. The smallest cannot afford to stay out, and Meta is already courting them with Muse for Small Business. The middle is squeezed. If it blocks, it risks becoming invisible. If it joins, it risks becoming an interchangeable supplier in someone else’s checkout.

Agents are also starting to deal with each other. Instinct already lets one person’s agent coordinate plans with a friend’s. A business with no door for agents may soon be missing from conversations it never knew were happening.

Why waiting loses

Waiting usually feels safe when a market is unclear. Here it is not, because the agent does not wait. It arrives through a browser on a customer’s password, or through a platform you sell on, whether or not you decided anything.

My view is simple. If agents are not on your roadmap for this year, you are already late. You do not need a finished strategy to start. You need someone accountable and a first decision on the table this quarter. Every month you wait, other companies are setting the terms you will inherit.

Four moves to start with:

1. Name an owner. The agent decision is a security, legal, commercial and platform call at once. Left alone, it gets owned by whichever team acts first.

2. Get in on purpose. Pick a door for each agent, check what your platforms have already switched on for you, and run one live test with real customers, the way Walmart did.

3. Compete on what agents measure. Make your price, availability, product data and policies accurate and machine-readable.

4. Require a name tag. Ask agents to identify themselves and whose they are. Treat one that will not as any unknown bot.

The businesses blocking or partnering on purpose are writing the rules of this market. The ones waiting will play by them.

If your company is working through this decision, reply to this email. I read every reply, and the hardest questions shape what I write next.

The word “dashboard” is older than the automobile. In 1846, it meant a board, sometimes a leather apron, that was fixed to the front of a horse-drawn carriage. Its job was to simply stop the mud that the horses’ hooves dashed up from hitting the people in the seat. Of course, it carried no gauges and no dials. It was just protection, not a display piece. In fact, the first mass-produced car in history, the Oldsmobile Curved Dash of 1901, was literally named after this mud shield. When engines moved to the front of the car in the early 1900s, the same board became a barrier against heat and oil. Since it was a flat panel sitting directly in front of the driver, manufacturers began mounting gauges on it. That’s it. As the etymologists put it, apart from its position in front of the seat, the modern dashboard has almost nothing in common with the original.

I have spent years building and using business dashboards, probably from every seat at the table. I owned the BI function for an entire organization, serving seven business units at the same time. I have built executive dashboards for leadership consumption and operational dashboards for day-to-day work. Now, while building AI systems, I see the dashboard is still the most in-demand artifact. When people describe what they want built, it is the first thing they name. My conclusion, from all of this, is straightforward: most enterprise dashboards are still just the shield on which the charts are mounted. The underlying function, though, is protection for the people above and the people below. Once you see that, you don’t get surprised by the adoption numbers, whichever way they turn out. You can also see clearly what the dashboard is going to look like in the era of AI.

The promise, in its own words

The dashboard’s intellectual history, interestingly, begins with a complaint. In 1961, D. Ronald Daniel of McKinsey published an article in Harvard Business Review titled “Management Information Crisis.” He flagged that companies were drowning in reports and starving for relevance at that time. For a long time, this continued to be a problem, until 1979, when John Rockart of MIT Sloan published “Chief Executives Define Their Own Data Needs” and formalized the idea of critical success factors.

If you read Rockart today, it’s striking how narrow the doctrine was. Executives should track a small number of areas where things cannot go wrong, and those areas should be defined by the executives who have to act, through structured interviews, one decision maker at a time.

In today’s world, both halves of that doctrine have been inverted. A small number of metrics grew to become dozens, and what was defined by the decision maker became defined by whoever was building the artifact. In that sense, the founding literature of this field would fail almost any executive dashboard in production today in a design review.

The first generation of software that was built on Rockart’s idea, called executive information systems, died quickly in the 1980s. The reason was that the information feeding those systems was incomplete, unreliable, and scattered across too many sources. Read that again, because that’s a description from the early 1990s, and it’s also a description of what today’s data quality review would tell you.

There is a supporting detail from the same era. A field study of 43 organizations listed the two major problems in developing these systems: getting accurate data and identifying executives’ information requirements. That is 1995, stating the entire thesis of this article.

The same study had one more number worth noting: the average cost of a first executive information system was roughly $325,000 in early 1990s money, which covered hardware, software, developers, and the cost of training. That is roughly three-quarters of a million dollars in today’s worth, for one system. At that price, you needed an executive to sponsor it and a key decision to be identified and committed to. This was not governance. This was basically a purchase order, which had a governance function built in. And this was also the thing which every later wave removed.

Five waves, one unsolved problem

The world of dashboards has evolved a couple of times in the past, in waves and waves of generations, and each generation of this technology solved the previous generation’s supply constraint. However, none of them touched the demand side.

The scoreboard for this forty-year effort comes from BARC and Eckerson Group, who surveyed 214 leaders in the field of data and analytics in 2022. They summarized in their finding that only a quarter of the employees actively use the BI tools their company pays for. They also found minimal growth across the seven years they tracked the metric. These seven years cover the entire self-service era. That generation was supposed to fix adoption, but it did not happen as expected.

Coming back to the number: a quarter of the seats actively used. That number has a widely repeated cousin, a figure commonly attributed to Gartner, saying 60 to 70 percent of dashboards go unused. I was not able to trace that figure to any Gartner publication, so it appears it originated from social media posts. The 25 percent figure, the one with a survey behind it, is still the critical one.

What a dashboard is actually for

So, why does this heavily unused artifact keep getting built without any signs of slowing down? The reason boils down to this: the dashboard is not primarily serving the decision. Its main job is to serve the relationship between the people above the decision and the people below it. Leaders often ask for more data because data is a cover for a call they will be held to, and teams happily supply more data because data is a cover for a recommendation they will be held to. Both sides are behaving rationally. In that sense, the dashboard is where both parties deposit their insurance, and it grows for the same reason insurance policies grow.

To be fair, I approved a lot of that growth myself. Every leadership dashboard that I have been responsible for almost always started with a clear question but then ended up as a negotiation. There was always one more panel requested from a stakeholder, which sounded reasonable, and I happily signed on to most of them. As a result, within a few quarters, the artifact became an information-bloated report with decisions somewhere buried inside it. As expected, people stopped opening it to decide anything. Rather, they opened it to retrieve a number whenever someone asked them a question. In short, it had become a proxy for the database, with a colorful UI and better fonts.

If we look at it, the plot twist is that the artifact is working as designed. It just was never designed for what its name says.

There is an easier way to understand this: most enterprise dashboards are, in fact, simply an alignment artifact, though they are sold internally as decision systems. The alignment function is real and legitimate, because organizations genuinely need one place where everyone can look at the same uncontested number to move forward. It’s also true that nobody is going to fund a $2 million alignment artifact. That is why it gets pitched as a decision system, and then we are surprised when only a few decisions trace back to it.

There is a category of dashboards where it demonstrably works: operational dashboards. It’s the kind you have seen, which watches a production line or an on-call queue. They succeed because they meet four conditions by construction:

• one type of user

• one class of decisions

• one owner

• a threshold that determines the action

Even Gartner, whose recent conference sessions carry catchy titles like “Are Dashboards Dead?”, acknowledges plainly that dashboards remain the backbone of enterprise analytics for operational oversight. The earliest dashboard I remember building ran on exactly this pattern, for my own team, and it worked because it was clear who was going to look at it and what action they needed to follow. Dashboard failure is usually concentrated at the strategic tier, where none of the four conditions hold together.

What AI eats, and what it cannot

With execution happening at an ever-faster rate, where we are building dashboards by the hour, the common worry is that AI will flood organizations with these generated dashboards. To be honest, this is going to happen, but I think, on the surface, it misses the deeper change. For forty years, the real governor on dashboard proliferation was the cost of a human builder. When a dashboard cost three-quarters of a million dollars in the nineties, or six weeks of a scarce analyst’s time until recently, someone needed to build a case and argue for it, and that business case was the prioritization bar. Now, with AI, since the build cost is plummeting to zero, it effectively means the last containment mechanism is gone. Just to be clear, AI did not create the dashboard problem. It was already happening. What it did was remove the only thing that was holding it in check.

In reality, AI is actually splitting the dashboard into two separate functions and treating them very differently:

1. The lookup function: that’s the proxy-to-the-database use case, which dominates real dashboard traffic. That’s the one which AI is genuinely eating. The capability jump here is real. In late 2024, the best models solved under 20 percent of tasks on Spider 2.0, a benchmark built from genuinely messy enterprise databases. By 2026, agentic systems on the public leaderboard clear 90 percent, with the caveat that benchmarks come with prepared documentation that production schemas rarely have. Directionally, though, it means nobody should have to navigate to a page to retrieve a number. They could simply ask for it. That use case is clearly ending, and rightly so.

2. The decision function: this one is different because it runs on something AI cannot generate, which is agreement on definitions. Every organization that I have worked in carried multiple live definitions of its most important metrics. When I owned the BI function, reconciling two versions of the same number consumed real time in almost every senior review. Sometimes, a dashboard ran up to six months just to get the alignment done before anybody saw an action out of it. Any project to standardize the definitions properly was always too long and too political to survive a budget cycle. That trade-off made sense when humans read those numbers, because a human spotting a mismatch in the quarterly reviews creates friction and a potential delay, but nothing worse. However, the moment software agents act on the numbers instead of humans reading them, that trade-off inverts. In simpler terms, a wrong revenue definition a person catches turns into an argument, but the same definition consumed by an agent that writes back to the system turns into a liability.

The industry has noticed. In January 2026, an open specification for semantic interoperability reached version 1.0 with dbt Labs, Snowflake, Databricks, and Microsoft behind it, and Snowflake shipped governed semantic views to general availability in the same quarter. Note what happened: four competing platforms converging on the same unglamorous problem inside a single quarter. Now that’s a signal. The standardization work that was never worth the ROI just became the prerequisite for the entire agentic roadmap. Gartner’s caution belongs next to that signal. They predict over 40 percent of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls.

The bill

Now let’s put the economics in one place.

Enterprises currently spend somewhere between $35 billion and $44 billion a year on BI, depending on which analyst is counting. Inside that, roughly a quarter of licensed employees are actively using it, a figure that has stayed flat for seven years. Confidence is moving the wrong way as well. A Salesforce survey of 552 American business decision-makers in March 2025 found confidence in data accuracy down 27 percent from its 2023 benchmark.

Against this, the industry is also citing strong returns: around $9 back per dollar spent, in recent Nucleus Research figures. On the face of it, these numbers look contradictory, but actually they are measuring different populations. The ROI studies are built from case studies of deployments that have worked. Return is measured on the survivors, whereas adoption is measured on everyone.

I have never seen a portfolio review inside a company that prices this gap, and I myself ran a function that should have run one.

What survives

The lookup dashboards are going to meet their natural death sooner than most expected, and so does the omnibus organization-level dashboard built by committee, which only ever existed because building was so expensive. The expense forced everyone’s requests into one project. When the build cost collapses, the consolidation logic collapses with it. So, uncomfortably, does the analyst role whose core skill is assembling charts.

Three things survive:

1. Operational closed-loop dashboards, which get better as AI handles the watching.

2. The shared-reality artifact: the one canonical screen a leadership team argues in front of, which survives precisely when it stops pretending to be a decision system.

3. The audited dashboards in regulated settings, where the artifact is the evidence trail.

Two things emerge as well:

• The semantic layer becomes the actual product, with dashboards demoted to views on top of it, because agents do not need visualization; they need definitions.

• The dashboard’s successor is an interface, probably an approval queue: “Here is what the agent is about to do. Here is the number it rests on. Here is where that number came from. Your call: approve or reject.”

Notice that, unlike the older versions, this interface has an accountable owner built into its very shape. That points to the test I would apply before building anything in this category now. Four fields:

• The decision this serves

• The person who makes it

• The cadence they make it on

• The threshold that triggers action

If you cannot fill all four, you’re just building a reference table, and that is fine. Just do not put one in the QBR and call it decision support. Give every dashboard an expiry date with a renewal condition. If its owner cannot name a decision it changed this quarter, or at max two quarters, archive it. An accountable owner without an expiry mechanism just produces a well-maintained graveyard.

The charts were never the durable part. Every wave of this technology rebuilt the display layer, and every wave inherited the same unresolved questions underneath: what the metrics mean and who acts on them. Those two things have held their value since Rockart wrote them down in 1979. Everything mounted on top has been replaced five times already. The mud is about to fly faster than it ever has. It’s time to check what your board is actually protecting.

Sources

• Etymonline, “dashboard”: https://www.etymonline.com/word/dashboard

• Oldsmobile Curved Dash, 1901, first mass-produced automobile (standard historical account)

• Daniel, “Management Information Crisis,” Harvard Business Review, Sept–Oct 1961

• Rockart, “Chief Executives Define Their Own Data Needs,” Harvard Business Review, March 1979

• Stephen Few, Information Dashboard Design (2006) — EIS failure account

• Watson, “Development practices for executive information systems: findings of a field study,” Decision Support Systems 14(2), 1995, pp. 171–184 (43 organizations; $325,000 average cost; two major problems finding)

• BARC/Eckerson, “Strategies for Driving Adoption and Usage with BI and Analytics,” 2022, n=214: https://barc.com/news/new-study-identifies-drivers-of-bi-and-analytics-adoption-in-companies-today/

• Salesforce/Tableau “Insight vs. Instinct,” March 2025, n=552

• Spider 2.0 (Lei et al., ICLR 2025) + leaderboard: https://spider2-sql.github.io/

• Open Semantic Interchange v1.0, January 2026

• Gartner press release, agentic AI project cancellations, June 2025: https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027

• Gartner Data & Analytics Summit 2026 session, “The Future of Dashboards”

• Nucleus Research analytics ROI (~$9.01 per $1, case-study based)

I have wanted to write this down for a while and kept finding reasons not to. The honest version starts with me getting it wrong myself, so it starts there.

When an organisation decides it is serious about AI, it is usually the same sequence. A team or a committee evaluates the tools. Security and legal write the policy. Procurement negotiates. Licences are bought and handed out. And finally a number lands in somebody’s goals for the year.

Then comes the part that was never written on the plan. The waiting. The gains are supposed to arrive faster and bigger than the old way of working could deliver. Mostly they arrive smaller and later than the case promised, and often they cannot be found at all.

If you are somewhere in that sequence, or about to begin it, this is written for you. And it is not because your organisation is doing it badly. Most of the ones I talk to are doing exactly what is being asked of them, competently and in a sensible order. The gap opens anyway, for a reason that has very little to do with effort or with the quality of the tools.

My own version of it was small and ordinary. By the second half of 2025, when the pressure to show something for AI had arrived in most executive goals, we had done everything the process asks for. The tool was evaluated. The reviews were done. The licences were bought and handed out. In fact one engineer started using it on his pull requests and told me it had cut the back and forth down considerably. He was right, he was pleased, and I took it as the start of something that would land the way it had been promised.

Then, for a while, very little else happened. There was not much resistance in any meeting. What followed was quieter, and very different from what I had imagined. Engineers would pick the tool up, use it for a week or so, and go back to working the way they always had.

Out of frustration, I asked one of them why. He said that on the changes he was making, it took him longer to describe what he wanted and check what came back than to make the change himself. He was not being difficult and he was not being nostalgic. He had done the sum on his own work, and it came out against the tool. I put the same question to a few others and got a version of the same answer.

I heard all of it as reluctance. That was my mistake, and I spent longer than I should have waiting for enthusiasm to do the spreading for me.

He was right. That is the part I sat with afterwards. The tool was good. The case for it was sound. And the engineer who had been told to use it was still right not to.

The arithmetic

His sum is worth writing out, because it is most of the story.

On a small, well understood task, an experienced engineer is faster alone. Describing the work to a machine and checking what comes back costs more than doing it.

The tool wins in two situations. When the work repeats often enough that the engineer and the tool learn each other. And when the job is big enough that the overhead disappears against its size.

Everywhere else, asking people to use AI is asking them to be slower on purpose. They feel it in their own working day whether they say so or not, and no amount of encouragement from me was going to change the sum.

Which is why the instruction most organisations settle on, use AI more, does so little. The useful instruction names the work.

Why this moves slowly, and why that deserves some respect

There is a second reason large companies move slowly here, and it gets less credit than it should.

Enterprise software is not judged the way a side project is judged. It carries service commitments, or a client’s experience, or a few thousand colleagues who need it to work on a Tuesday morning. Reliability outranks efficiency there, and it should. So when something genuinely capable arrives, the responsible response is rarely speed. It is a run of dull, necessary questions about failure modes and accountability, and then a decision.

Most of the organisations I work with manage the questions well. Far fewer reach the decision.

There is a harder version of this that many leaders are living through, and it deserves saying plainly. When a company moves through waves of restructuring, its capacity to execute falls. At the same time, expectations for revenue and for the quality of the work do not fall with it, and they should not, because those expectations carry the future of the people who stay. That is what makes those periods hard to lead through. It is also when the temptation is strongest to announce a tool as the answer. The people who remain are being asked to meet an expectation that has not moved, with a capacity that has. Anything that genuinely helps them is a way out. Anything that reads as a plan to need fewer of them is a threat, whatever the slide says.

I have stood in front of a room in that condition. You can feel which of the two things people have decided you are saying, usually inside the first minute, long before anybody asks a question.

Two reactions, and what they have in common

Instead of that decision, one of two things tends to happen.

The first is the stampede. Go all in, buy widely, run a dozen pilots, put up a slide about being AI-first, and treat velocity as evidence of seriousness. From the outside it looks decisive. Inside, it usually means the hard question has been skipped: where does this genuinely improve the work, where does it not, and who will stand behind that answer?

The second is the freeze. The ground is moving too quickly, the winners are not obvious, so the sensible course is to wait and enter later when the picture has cleared. It comes with a paper attached, usually a careful one. The trouble is what that paper looks like a year on, which is the same paper with the dates changed, because nothing happened in between that would have taught anybody anything new. The organisations I have watched wait did not arrive later with better judgment. They arrived with less. Judgment about a technology is built by using it on something that matters.

These two are usually described as opposites, yet they produce the same result. The decision about where the technology belongs has been handed outside the organisation, to the market in one and to time in the other, and no one inside owns having chosen.

There is a great deal of fear in this market, and a number of people busy making a living from it. What a leader can usefully offer in the middle of that is a decision. This is where we move. This is where we deliberately do not. And I will answer for having said so.

You have been here before

Most people reading this have already been in a version of this situation.

Not this technology, but this shape of problem. Something arrives that is genuinely capable and genuinely unfinished. The organisation is unevenly excited about it. The budget wants a line item. And you have to work out what it changes and what it leaves alone while the room watches you decide. A platform migration, a cloud move, an outsourcing wave, a data consolidation: all of them put a leader in the same position.

I have been in it four times. In two the technology was AI. In the other two it was not, and those two carry more weight here, because they are what tells you the pattern belongs to how work is led rather than to any particular technology. A method that only holds for the current generation of tools is closer to a fashion than a method, and it will need replacing as soon as the generation turns.

Here is what stayed constant across all four, and what each one cost me.

What stays constant

Four things. The first is the decision. The other three are what makes it hold. None is complicated, and the difficulty is doing them while the room wants a faster answer.

Decide where it earns a place. This is the whole job, and most organisations move past it too quickly.

Qualify the work first, the way you would qualify anything else asking for budget. The tests below decide whether to hand it to a machine, not whether it was worth doing, and plenty of AI work passes every one of them while being worth nothing to anybody. The letters AI on a proposal are not a reason to skip the question.

What remains is three questions that decide whether, a verdict, and one deliberate exception.

One. Does the value clear the overhead? Does it repeat often enough to compound, or is it one job big enough that the setup cost vanishes against it? Describing work to a machine and checking it is not free, and on small one-off tasks it costs more than doing the work.

Two. Is the shape stable? Can you say what good looks like before you see the output? Novelty defeats delegation.

Three. Can it be checked cheaply? Can a person tell the output is right faster than producing it, or sample a batch and be confident? Otherwise the cost has moved rather than gone.

Most stalled programmes I have seen were funding work that fails the third one. The shape is usually the same. Something is being summarised or drafted, the output looks excellent, and the person receiving it still has to read the source to know whether it is right. Verification cost rarely appears in an AI business case. When a person cannot check the output faster than doing the work, the cost has moved rather than gone, usually somewhere harder to see.

The test bites hardest on work the team could not have done itself. Hiring the machine to do what nobody in the room can do sounds like the obvious use, and it is the most dangerous one, because a team that cannot produce the work often cannot check it either. But that is the line that decides, not the capability gap. Where the output is measurable without the missing skill, a test suite, an experiment, a number that can be looked up, work beyond the team’s reach is one of the best places a machine earns its keep. A cheap check is still not a promise that the machine reaches the bar, only the way to find out quickly. When what comes back keeps failing the check, that is the tests answering no in production, and that work gets parked, with a date.

The verdict comes in three forms, not one. Fund it. Refuse it, and say why out loud, because a refusal with no reason gets quietly reversed by whoever is keenest. Or park it with a date to look again, because work that fails today passes two quarters later, when checking has got cheaper or the models have moved. A parked item with no date is a no that nobody had the nerve to say.

Then one deliberate exception, small and named. Some work cannot answer the first question, because nobody can say in advance what it will find or what the finding will be worth. Some of it is still worth funding, because what you are buying is judgment rather than output. Hold a capped line for it. Say it is there. Keep it capped. Uncapped, that line is the stampede. Missing, it is the freeze.

Give people a bounded space to try. The question that governs this one decides how rather than whether: if it goes wrong, how far does the damage travel? A large blast radius is not a reason to stop. It sets how much freedom you can give.

Most organisations tell their teams to experiment safely. Far fewer write down what that permission covers, so teams guess, and guessing produces paralysis in the cautious and recklessness in the confident.

The version that works is unglamorous and specific. Tier what people may do by the damage a mistake would cause. Small blast radius: let the machine run and sample the output. Medium: let the machine draft and have a person accept. Large: have a person produce and let the machine check. On a single page, circulated, that is what a safe space looks like in practice. A permission slip with a boundary on it, which lets a cautious team move faster and keeps an eager one out of trouble.

Give away authorship. Very little scales out of one team on merit alone. It scales when other leaders have their fingerprints on it.

I learned this later than I should have. Early on I would design something sound, present it well, and watch it stop at a boundary that appears on no organisation chart, which is the edge of my own authority. The approach that works is harder on the ego and better for the outcome. Bring in the leaders whose work the thing touches and have them write their own part of it. What comes back is messier than what I would have written, and it comes back as theirs, which is the only version that survives contact with an organisation you do not control.

Keep a gate, and measure it. Anywhere a person accepts or rejects what a machine produced is a gate. A gate with no name against it becomes a queue. A standard with no gate behind it becomes advice.

So put a name on each one. Measure how often that person accepts. And put the budget for the people at the gate on the same page as the budget for the tools feeding them. Movement in an acceptance rate will tell you more about whether this is working than most of the dashboards you will be shown.

None of that is unfamiliar. It is roughly what leading through a technology change has always required, and it holds when the technology underneath changes, which is the main reason to trust it.

Four times, and what I refused each time

The same shape each time: what I was asked for, what the real choice was, what I refused, and what came of it. Two involved AI and two did not. Every figure comes from that organisation’s own measurement, none are independently audited, and companies are not named.

One. Predictable delivery while the organisation was getting smaller

A global consumer media company. A hundred-plus person product, engineering, design and QA organisation across three countries.

I was asked for delivery predictability while the organisation was also reducing capacity. So the real question was not how to make delivery predictable. It was how to hold it steady while the shape of the team kept changing. A harder problem, and a common one.

Two moves answered it, and only one of them involved AI.

The first was a standard. I partnered with the leaders whose work the delivery lifecycle crossed, engineering, QA, design, research, data science and customer support, bringing product from my side, and the customer’s expectations with it, to define a repeatable path from idea to production: the process, the artifacts, and a gate at every handoff with a named owner. The choice there was genuinely close. I could write it myself in about three weeks, and it would have been the better document. Or I could hand the pen and have each function write its own part, and take a quarter to get something looser than I wanted.

I took the second. It cost a quarter of calendar time and a standard lighter than the one in my head, because a document written by seven people converges on what all seven will actually do. I still wonder what the missing rigour cost us later. The rest was my own time; there was no squad and no budget line behind it. What I bought was adoption: the standard was approved and became the de facto format across the company, in teams I had no authority over, because their own leaders had written it.

The second move was AI, and no one had asked me for it. AI-assisted development was the only answer I could find that closed the capacity gap at the ratio we were working at, and it brought a second problem: a mandate would have been heard as an announcement about people’s own replacement. So what I refused was to run it as an efficiency programme. Not by hiding the numbers; they were the same either way. An efficiency programme is defined by where the gains go. Ours went into output, with the team we had, and none were booked as a reason to need fewer people.

We started with code migration, where the arithmetic worked: a body of work big enough that the tool’s overhead vanished against it, and work that eats engineer bandwidth while adding nothing the business is asked to prioritise. Compressing it with AI freed our most expensive constraint, the time of a shrinking team, for the work that carried revenue. It also gave a large number of engineers a low-stakes place to learn where these tools are strong, where they are unreliable, and what they cannot do at all. By the time anyone was asked to trust AI output on work that mattered, they had formed their own view of its limits rather than inheriting mine.

Then the two moves clicked together. A standard with a gate at every handoff does not care whether a person or a machine produced the artifact in front of it. Ours was written so that a person and a model would read it identically, which is what made AI output reliable enough to ship. Six months after rollout we were running at close to 80 percent of projects on time, through the restructuring, with cycle time down sharply and regression cycles closing in days rather than weeks.

If your organisation is reducing headcount while expecting the same output, the instinct is to announce AI as the answer. That announcement is usually what stops it working.

Two. The payment system I refused to replace

A private-equity-backed B2B sales and marketing data company. Six acquired products sitting over three shared databases.

The brief was speed to market. We were rebuilding the largest revenue product end to end, and the question underneath every decision was what to build ourselves and what to take from somewhere else.

The principle I work to is that you build what the customer will judge you on and you take everything else. Here that meant search and retrieval, the quality of the data coming back, and the interfaces around both.

Order management and payments were where the principle stopped being comfortable. We had an in-house system, built a couple of years earlier, that worked. It was slower and plainer than what we would have got by putting Stripe in.

Two options, both defensible. Integrate Stripe: several weeks of work to wire it in and harden it to a standard we would be comfortable taking real money through, and at the end of that a payment experience no customer would ever remark on. Or keep what we had, ship on the date, and go to market with the least modern part of the product still in place.

Stripe was the better system. That was never in question. I had to decide whether it earned a place in this release, and at that point it did not. The MVP existed to tell us whether customers could find the right information, search it well and get accurate data back. Payment had to complete. It did not have to be elegant.

It cost me weeks of defending a worse answer in front of people who could see the better one sitting right there, inexpensive and available. That is more tiring than it sounds. It also meant that if payments had failed in front of a customer, the reason would have been a call I made, and it could be named.

The product reached market on the schedule that mattered, and the payments decision was taken later against real usage instead of a guess. There is no AI anywhere in that story. It is the same judgment I now apply to AI tools every time. Not whether the new thing is better, but whether it earns a place in the release in front of me.Three. The time AI told us what not to build

The same media company as case one. Advertising, the largest of three digital revenue lines.

I was asked to improve the reliability of a platform on which reliability had never been defined. Everyone could tell you the experience was wrong. Nobody could tell you by how much. No number meant no budget anyone could argue for.

So we built the measure first. One that separated reloads the platform caused from refreshes users had chosen. We measured the estate as it stood and put a rate on it: 20 to 30 percent of sessions, by content type. With that number in hand the work became fundable. Worth noticing on its own: the instrument was the leadership act, and it needed no technology at all.

A page like ours was never just our code. Content, markup, styles, custom pieces, a stack of third-party scripts, all of it running on a browser whose memory management no public document explains. Nobody outside Apple can tell you when Safari decides a page has had enough; you learn it by watching your pages crash. The rabbit hole was genuine. You could optimise layer after layer and never know whether an exit existed.

Generative AI is what made that search finite: it read and mapped the whole monolith and every place a reload could fire, in one sweep. It produced a finding, not a fix. The dominant driver of the reloads sat outside our code: it was how much the pages asked the browser to hold, against device-memory limits that were not ours to move. A cleaner codebase would have bought margin at the edges without moving the number. So the expensive rewrite we had been circling was the wrong answer, and the rest of the hole was not worth the scope we had.

Nobody could have said in advance what that read would find, or what a finding would be worth, so it would never have cleared the first test. It was still the most valuable thing AI did on the whole programme, because what it produced was a reason not to build. That is what the capped line is for, and it is a use I have yet to see on a vendor slide.

What I refused was the obvious lever, which was to pull ads out until the pages behaved. Fewer ads would have improved the reliability numbers inside a quarter, and broken the delivery we had promised advertisers, which is where the revenue lived. I was unpopular for a while for saying so.

Once we knew the biggest lever was not in our code, the job became living within browser and memory limits we could not move. A dedicated squad experimented its way to where those thresholds sat, and the answer came out as a working rule: an ad every third slide, with a hard ceiling on the total in a long gallery. Enough headroom to keep the session alive, enough ads to make good on every campaign. That took eighteen months, and the work was tuning rather than rewriting.

Involuntary session failure fell to a small fraction of what we first measured, viewability rose on inventory we had already sold, and the metric outlived me and remains the company standard.

Four. Seven people, and a date the business believed

A broadcaster and streaming group in India. The data function behind a large advertising business.

I was asked for dashboards that each function could treat as its source of truth: sales, finance, streaming engagement, and more, across streaming and linear television, with delivery dates people could rely on. The team behind that ask was seven people working ad hoc: four data engineers, a BI engineer, a data manager, and one project manager standing between the contractors and every stakeholder with no authority to prioritise anything.

What I refused was everything we could not actually deliver. We productised the data layer itself: one architecture underneath, the tables and pipelines fixed once, so the same data could serve every function’s cut without rework, with the customisation living at the output layer where it belongs. On top of that we built a capacity-based intake, so no date was committed before demand had been reconciled against what seven people could absorb, and the sequence of dashboards was agreed with the leaders whose businesses they served. Some requests waited and some were declined, by me, with a reason attached. And we enforced the measurement licence windows inside the platform rather than in policy, which is the difference between a rule and a rule that gets followed.

It cost me bespoke responsiveness and about two quarters of goodwill. Anyone doing this should know that the unpopularity arrives well before the credibility does.

We finished at 90 percent of data product projects on time, with the remainder delayed against a stated business case rather than simply missed, and platform run cost cut by more than half, partly by finding the licences nobody was using. There is no AI in that story, and it might be the most AI-relevant one here. AI is a layer you add on top of a data foundation, and an organisation that has productised that foundation, and learned to decide what it will not promise, has already done the hardest part of adopting agents.

The strongest argument against all of this

The serious objection is that in a field moving this quickly, deciding early is how an organisation commits to the wrong thing. Optionality has real value. A leader who fixes an allocation of work in March may look foolish by September, when the tools have changed underneath the decision, and the cost of having committed is paid in rework and credibility.

I take that seriously. I also think it argues for a narrower conclusion than it appears to reach. Deciding where something earns a place today is not the same as committing to it permanently. The tests get re-run as verification gets cheaper and the models improve, and work that failed last quarter passes this one. What does not survive the objection is declining to decide at all. Waiting produces neither optionality nor learning. It produces delay, and a year later the organisation has the same decision in front of it with less experience to bring to it. And none of this refuses optionality. It prices it. The capped line is optionality with a number on it, bought on purpose, instead of optionality as the reason nothing gets decided.

There is a related objection to the arithmetic itself, which is that it is already dated. The overhead has fallen since 2025 and will keep falling, so the threshold where these tools start to win keeps moving down, and any rule of thumb built on today’s economics will be wrong soon enough. That is correct, and it changes the answer rather than the method. The threshold is a number to re-check each quarter, not a principle to adopt once.

What I have not seen

I should be straight about the limits of this, since I would not trust anybody who was not.

In my own record, the four have never all shown up in the same place at the same time. Each of the cases above does some of this well, and none of them carried all four across a whole estate, including anything I ran myself. Organisations that carry all four at once no doubt exist. Expect them to be rare, because this work is expensive in a way that does not show up in a technology budget, which is most of why it goes undone.

That does not make the method theoretical. It makes the complete version something to aim at rather than something to assume. If somebody tells you they have transformed an entire operating model in two quarters, ask which gates have names against them, and watch what happens next.

If you are starting on Monday

One exercise, and it takes an afternoon.

Take three places where AI is already touching real work in your organisation, and take them from different parts of it. A team coding with it. A workflow outside engineering that runs on it, in finance, in support, in legal. And somewhere a report or an email being drafted with it. For each one, find the moment where a person accepts what the machine produced or sends it back.

Most leaders can name that person in a minute, and the name is not the point. The point is to go and watch the moment. Somewhere in your three, a person is accepting quickly and shipping more because of it. Somewhere else, a person is spending longer checking the output than the work used to take, and saying nothing. Both look like adoption on a dashboard. They are opposite answers, and the difference between them is the whole subject of this piece: the first is work where the value clears the overhead, the second is work that should never have been handed over, or was handed over with no boundary and no owner.

That afternoon gives you your Tuesday. Run the struggling ones through the three questions, and be willing to park them with a date. Ask the excelling ones what boundary they would want written down, and write it. You will learn more from those two conversations than from your next vendor evaluation.

Then decide one thing you are not going to do this quarter, and tell people why. That is the harder half of the job, and it is the half that makes a leader worth following through a period like this one.

A note on how this was written

I used AI to write this, and I would rather say so than have you wonder.

For years I wanted to write and could not find the hours. Typing was never where my thinking happened. So I talk instead. I ramble through an idea out loud, argue with myself, go over the same point four times, and use AI to structure what comes out, tidy it and catch the grammar I get wrong. I also use it to check myself, to find whether a number I half remember actually holds and where it came from. That is how one claim got cut from this piece.

If you were hoping for something with no AI in it, this is not that, and the next one will not be either.

Notice where the time went instead. Writing this by hand would have taken a few hours across a few sittings, most of it typing and fixing commas. Those hours went somewhere better. They went into being asked whether a claim holds. Into going back through my own record to check that a case happened the way I remember it. Into cutting arguments that did not survive a single follow-up question. The brainstorming, the back and forth, the challenging of my own statements. That is the work. The machine took the typing.

Which is the same argument as the rest of the piece. Used with judgment, on the work where it earns a place, this frees you to think harder rather than produce faster. Use it that way, and give the hours back to the thinking you have been putting off. This piece is my own small example of it.

What this publication is

I am writing in public because I am still working it out, and because the people I most want to hear from are the ones going through it now, not the ones selling a finished answer.

The belief underneath it is unexciting on purpose. AI is a tool. A serious one, and one in a long line of technologies that have changed how enterprises reach their outcomes, which means it deserves neither worship nor cluelessness. It deserves judgment. So I write about where I am finding it adds value, where I am finding myself stuck, and what I would decide differently now. If you are seeing the same problems, or different ones, or solving them another way, say so. That is the kind of learning I cannot do alone, and it is most of why this is public.

It will not only be about AI. Leading teams is my trade: people whose growth I am responsible for, stakeholders who depend on what gets delivered, most of it done from India, inside the operating model of a global capability centre, which has nuances of its own that rarely get written about honestly. So the leadership journey will show up here too. How I have changed over time, what the day-to-day teaches that the long view misses, what building something of my own is teaching me now, and how to carry the uncertain stretches without drama. Not a diary, and not everything that crosses my mind. The thoughts I have spent real time on, worked into something you can use, and only when they are worth yours.

Each of the four cases above will get its own fuller anonymised write-up, with the numbers kept and the identifying details out, and the reasoning I have left out of the short versions. I would rather publish something worth your time than keep to a calendar, so there is no fixed schedule here and no dates on those. Subscribing is how you will know when one lands.

If you are somewhere between the stampede and the freeze and looking for a way through that is neither, this is written for you. If you try any of it and it does not work the way I have described, that reply is more useful to me than agreement, and it usually makes the next piece better.

Evidence notes, dated

The argument stands on the four cases rather than on these figures. Each carries its date so you can judge how stale it has become.

• 2026. McKinsey’s global State of AI survey: roughly nine in ten organisations report regular use of AI in at least one business function, and the share scaling it enterprise-wide rose to 44 percent from 38 percent the year before. Eighty percent of respondents say AI has improved their individual productivity, while 37 percent attribute any EBIT impact to it, a figure essentially flat year on year, and only about 6 percent report a material one. This is the gap between individual gain and organisational return, measured by somebody other than me. McKinsey, The State of AI

• 2025. The share of firms abandoning most of their AI projects before full deployment rose to 42 percent, from 17 percent a year earlier. Reported via CIO Dive, 2025. The year the pressure arrived is also the year the abandonment rate more than doubled.

• April 2026. WRITER’s survey of 2,400 C-suite leaders and employees: 97 percent call AI beneficial while 29 percent report significant return from generative AI, and 48 percent call adoption at their own company a disappointment. 75 percent say their AI strategy is more for show than for internal guidance. That distance between enthusiasm and result is the stampede, measured. The same release leads on a separate finding, that 60 percent of companies plan to lay off employees who will not adopt AI, which is a fair sample of the fear in this market. This piece takes no position on it. BusinessWire, 7 April 2026

• December 2025. Deloitte’s chief technology officer, on the firm’s 2026 Tech Trends work: companies are putting roughly 93 percent of their AI budget into technology and roughly 7 percent into the people expected to use it. Which is what skipping the decision looks like on a budget line. Fortune, 15 December 2025

• Later evidence gets appended here with its date. If it contradicts the argument, this piece will say so.

About the author

I have spent close to two decades building products and technology from India for global markets: the United States, Europe, and Asia. Distance from the user raises the bar rather than lowering it. A customer in New York or London does not care where a platform was built; they hold it to the standard of anything built next door, and my teams and I were measured against exactly that. There is no pass for the distance. Understanding users and markets you do not live in is part of the discipline, and it is the harder part.

The route ran through very different rooms: enterprise systems at a digital industrial company, a global media network, a century-old publishing house, a private-equity-backed data SaaS business, and now a venture of my own in the agentic AI space, with consulting alongside. I am an engineer by training and an MBA by choice, so I argue for technology in the language of return, and question business cases in the language of engineering. Watching which lessons transfer between those rooms, and which each industry has to relearn its own way, is where most of my judgment comes from.

The technology has turned over more than once in that time: consumer platforms serving hundreds of millions of monthly users, and holding around a million of them at once on their peak nights, the streaming and data build-outs behind them, a generative AI product shipped to revenue while the category was still forming, and lately coding agents and an AI-native development standard across a hundred-plus person engineering organisation. The lesson that survived every wave is the one this publication is built on: the technology changes, and the job of deciding where it belongs does not. I write about the operating side of that job: how work is allocated between people and machines, how standards and gates get adopted rather than announced, and how organisations decide what to fund and what to refuse.Sources and disclosure

The four cases are from my own operating record at three employers between 2020 and 2026. Companies are not named. Fuller anonymised versions will follow here, each with its own disclosure boundary, and the private named record is available on request. Every internal figure comes from that organisation’s own measurement and is not independently audited, and each case carries a single figure by design. No profit and loss ownership is claimed. The tests and the blast-radius tiering are my own working frameworks. The engineering of agent loops, evaluations and verification is a separate subject and not one I am claiming here.