The Wrong Search: Where Is the AI Money?

Being a leisurely account of how perfectly sensible companies buy artificial intelligence backwards, with some remarks on what might be done about it

I. In which somebody is told to go and find a use for it

I have a friend whom I shall call Harris, partly to protect him and partly because it annoys him. Harris is a chief operating officer, which means he is the person in a company who actually knows how things get done, and who is therefore the last person anyone consults about anything.

Some time ago, Harris was summoned to a board meeting and given an instruction. The instruction was: find out what we should do with AI.

He asked, reasonably, what problem they had in mind. The chairman said that was rather the point of the exercise. A competitor had issued a press release. An investor had asked a question at lunch. And the company's software supplier had, in the course of an ordinary renewal, thrown in a quantity of artificial intelligence the way a grocer throws in a free onion, so that the thing was now sitting in the building, paid for, unused, and faintly accusing.

"We've decided it will be AI," said the chairman. "Go and find out what for."

Harris told me this over dinner, and I laughed, and then I stopped laughing, because I realised I had heard exactly the same instruction in perhaps a dozen companies, given by perfectly intelligent people who would have been appalled to hear it applied to anything else. Nobody says, " We've bought the machine, now go and find out which product it makes. Nobody says, " We've hired a Frenchman, go and find something for him to translate. The order of the thing is so obviously wrong that in any other department it would be a joke.

And yet somewhere in nearly every large organisation on earth, at this moment, somebody is running a search for AI use cases, and the search began with the answer.

This essay is about why that search fails, and it will take its time, because the failure is interesting and the reasons for it are not what people think. I will come, eventually, to what one might do instead. But I want to be fair to the chairman first, because he is not a fool, and the situation he is in is a good deal harder than it looks.

II. In which the chairman is defended, up to a point

It is fashionable to explain all this as hype, or mania, or a bubble, and to shake one's head at the executives who fall for it. I find this both insulting and useless. Insulting because the executives in question have generally run companies through three recessions and a pandemic, and useless because "they were foolish" is not a diagnosis one can act on.

What is actually happening has two sides, and the chairman is squeezed between them.

On the one hand, there is a truly enormous amount of money that has been invested in building artificial intelligence, and that money needs someone to buy the stuff. So it arrives at the chairman's company through every door and window at once. It comes as cloud credits. It comes bundled into software renewals he would have signed anyway. It comes as vendor roadmaps that assume he is already "on the journey," and as consultancy maturity models that place him, with great sympathy, at the bottom of a staircase. It comes through his board, all of whom read the same three publications, and through his golf club, which is worse.

None of these channels brings him a question about his business. They bring him an instrument and a deadline.

On the other side, and this is the part the hype theory misses entirely, the chairman is in a corner. Demand for what his company sells has been flat for years, so he cannot grow his way out of anything. Costs are rising, from energy and materials, and a supply chain that has come apart at the seams, so he cannot cut his way out either. Every classical response to a stagnant market, wait for the recovery, squeeze the costs, nudge the prices, is blocked at the same time. He has pulled every lever on the panel and the train has not moved.

And then somebody walks in with a lever he has not pulled.

That is the whole psychology of the thing, and it explains what hype cannot: why the spending is so confident and the returns so absent. Deloitte asked 1,854 senior executives across Europe and the Middle East, in the autumn of 2025, how things were going. 85 per cent had increased their AI spending over the previous year. 91 per cent planned to increase it again. The typical expectation for a satisfactory return was 2 to 4 years, in a world where an ordinary technology investment is expected to pay back in 7 to 12 months. 6 per cent had actually got their money back within a year.

Those are not the numbers of a market of buyers. They are the numbers of a market being supplied to people who cannot say no.

So the chairman's instruction to Harris is not stupid. It is what a cornered and well-meaning man says when a lever is put in his hand. But it does reverse the natural order of things, and a search that begins with the answer runs into four walls, one after another, and I shall take them in the order in which Harris hit them.

III. The first wall: you can only find what you can see

Harris did what any competent person does. He assembled a team, held workshops, invited the business, and produced a list.

I have seen a good many of these lists, and I can tell you what was on it without having looked: document review, knowledge search, a coding assistant, a customer chatbot, risk triage, and something about personalising the sales letters. I know this because I have collected such lists from firms in insurance, logistics, law, retail, and public administration, and they are, aside from the letterhead, identical.

Think about that for a moment. Five industries, five completely different ways of making money, five lists that could be swapped without anyone noticing. It cannot be that all five firms have the same opportunity. It must be that all five are using the same method of looking, and that the method finds the same things regardless of where it is pointed.

The method is: start from the tool. And a tool can only be pointed at work that is visible, which is to say, work that has already been turned into documents, tickets, emails and transcripts. The shortlist is not a list of opportunities. It is a map of where data happened to pile up over fifteen years of IT spending, and there is no reason on earth for that map to coincide with the map of where the company makes its money. Usually it doesn't. The money is somewhere in the middle of the building, in a process nobody has written down, and the data is out in the corridor, where the copier is.

Which brings us to the deeper trouble, and it is one I did not properly understand until I had been an architect for a good many years.

Ask any large company for a description of its processes and you will be handed documents. Process maps. Procedures. An operating model with boxes and arrows. And these documents are, without exception, fiction. Not lies, exactly. Aspirations. They describe how the work would be done if the world were tidy. They do not describe the exceptions that never made it into the manual, the escalation that happens over the phone because the workflow tool has no button for it, or the twelve years of judgment carried around in the head of the one woman in claims to whom everyone sends the awkward cases.

The real process lives in people. It has never needed to exist anywhere else, because people were the ones running it, and people carry the undocumented remainder for free. They have done so since the invention of the office, and nobody noticed because it never cost anything.

It costs something now. Hand the work to a machine that can only act on what it has been told, and the gap between the documented process and the real one suddenly becomes expensively visible. Harris's team, I realised, was not looking for a use case at all. It was trying to build, in six weeks of workshops with sandwiches, a model of how the company actually works, and the company had never possessed such a model in its life.

IV. The second wall: the data is the wrong data

Suppose Harris gets past that. Suppose he finds the pile of data and points the machine at it. The relief, I am sorry to say, is brief.

The data was made by people, for people. And people write down what happened. They do not write down why. A case note assumes the reader knows the client. A decision record states the decision and leaves the reasoning in the room where it was made. The options that were considered and rejected leave no trace at all, and neither does the reasoning behind the exception, which is precisely the reasoning one would most like to have.

Human data records outcomes. A machine that is to learn anything needs the mechanism. These are two different datasets, and nobody ever wrote the second one because no human reader ever needed it.

Now, this gap can be closed by hand, and firms do close it. They hire people to extract, label, and reconstruct; they pull their best experts off the day job for months to explain what they meant. It is expensive, and I have no objection to the expense. My objection is to what nobody mentions at business-case time: that it is a one-off. It repairs the data you had on the day you started. It does nothing whatever about tomorrow, because the process that produced yesterday's unhelpful data is still running, producing more of it, every working hour. Six months later, the gap is exactly where it was. The experts are back at their desks. The budget is gone.

The only durable answer is to change the process itself, so that the data the machine needs is produced as a natural by-product of doing the work, the way a properly instrumented engine produces its own telemetry. That is not a data project. It is a redesign of how the work is performed and recorded, and it has to be decided before anybody chooses a tool, not afterwards.

Here is the whole argument of this essay in one sentence, and I shall not apologise for it. Bolt AI onto the processes you have, and you get one round of value from a corpus you built by hand, followed by a slow decline. Rebuild the process to emit the right data, and things get better every week while your competitor commissions another labelling exercise.

V. The third wall: in which we meet Mr Amdahl and Mr Goldratt

Suppose Harris gets past that too. He finds a real case in a real process with real data. He can still lose, and this is where his six pilots died, so I want to be precise about it.

A tool-first search finds work at the level of the task, because that is the altitude at which a tool is visible. Money exists at the level of the process or the product. These are not at the same altitude, and the difference is not a matter of opinion. It is arithmetic.

Take a step that occupies eight per cent of a process. Automate it beautifully. Make it fifty per cent faster. You have improved the process by 4%. For that four per cent, you have bought a licence, an integration, a monitoring obligation, a review layer, a security assessment and a permanent new way for things to go wrong. There is a gentleman called Amdahl who wrote this down as a law in the 1960s, for computers, and it has been mugging computer architects in dark alleys ever since. It works identically on organisations. Nobody in a workshop has ever heard of it.

Then there is Mr Goldratt, who is worse. Amdahl only says the gain will be small. Goldratt says it may be negative. His theory of constraints holds that every process has one step that limits it, and that speeding up any other step does not speed up the process. What it does is deliver work faster to the real bottleneck, where a queue now forms. Work-in-progress rises. Cases stuck in the queue take longer, not shorter. And somewhere in the building, a dashboard is celebrating a triumphant improvement in the step you touched, because that is the only thing it was built to measure. The people downstream can see exactly what has happened. The programme cannot report success.

I draw two rules from this, and they are the cheapest advice in this essay. First, if a single use case is enough to produce the effect, there is no effect. Real economics begins when an entire layer of a process is removed, or when the actual constraint is relieved, not when an operation within it is accelerated. Second: find the constraint before you find the use case, because automating anywhere else is, at best, expensive and, at worst, actively harmful.

Neither of these is a change a use-case programme can propose. A programme built to evaluate cases can only ever produce cases. It is constitutionally incapable of saying "the answer is not a case."

VI. The fourth wall: in which the managing director prefers interns

And now the part that everyone gets wrong, including, for a long time, me.

The pilot works. It really does. The model does what the vendor said it would do. And the person who owns the process, the one who would have to run it every day, declines to take it into operation. The programme writes this down as "resistance" and schedules a change-management workshop.

It is not resistance. Look at what the poor man is being offered.

His process today is built from parts that behave the same way every time. When something goes wrong, there is a rule that was broken, a person who broke it, and a way of putting it right. That is what makes the process auditable, insurable, and defensible before a regulator. It is not a nicety. It is the thing that lets him sleep.

A probabilistic component does not weaken that structure. It breaks it. Who is accountable when the output is wrong but nobody made a mistake? How is a wrong answer detected at all, when it arrives fluent, confident, and correctly formatted? And who handles the twenty per cent of cases that are non-standard, given that handling them means keeping the entire human layer in place, so that you now run two systems where you ran one?

Those questions have answers. But they are engineering answers, and they begin with understanding why a language model produces a distribution of results rather than a result. That is the subject of my book, and I shall not repeat it here, except to say that the process owner has understood the shape of the problem without any of the vocabulary. He is being offered an unmeasured operational risk in exchange for an unmeasured saving, and he says no, and he is the most rational person in the room.

One scene has stayed with me. An international audit firm, a working pilot for reviewing documents in insolvency cases, and the meeting at which it was to go live. The managing director, a man of long experience, listened to the whole presentation with perfect courtesy and then said: "That's very clever. But I'd rather have ten interns reading those documents. I know how to work with interns. They'll learn. And at the end of the year, I'll have three good ones I can keep."

Everyone in the room thought he had missed the point. He had not. He had noticed, in about four minutes, that the pilot had no way of learning from its own work, and that the interns did, and he had priced the difference correctly. I have since put that sentence to a good many AI programmes, and none of them has had an answer.

I have watched the full funnel run its course, once, from beginning to end. Around forty candidate cases, chosen with real care by an AI team working alongside the business. Six survived to pilot readiness. None was deployed. That is one team's experience and not a market statistic, but the official statistics rhyme with it in a way I find uncomfortable.

When the Office for National Statistics asked some fifty-five thousand British businesses what stopped them from adopting AI, the most common answer was not cost, at twenty-one per cent, nor skills, at sixteen per cent. It was difficult to identify a use case: 39 per cent. The most common obstacle to using the machine was not knowing what it was for.

And the shape of adoption since then tells the same story from the other end. By the summer of 2026, roughly 35 per cent of British firms with 10 or more staff were using AI, up from 12 per cent three years earlier. Adoption had nearly tripled. The average adopter, meanwhile, had gone from using 1.4 AI tools to 1.6. Breadth tripled; depth barely moved. That is what a market of experiments looks like when almost none of them turn into anything.

VII. In which it is observed that the clock is running

There is one more cost to searching in the wrong order, and it is the one that turns a slow programme into a write-off.

Hold two numbers next to each other. The expected payback on an enterprise AI investment, according to the Deloitte figures above, is two to four years. The useful life of any particular model generation, integration pattern or orchestration framework is considerably less than that, and nobody serious will give you a number, because the honest number changes every quarter.

Those two figures do not fit. A deployment built around this year's capabilities can be delivered, successfully, on time and on budget, and be obsolete before it has returned its cost, overtaken by a capability that arrives as a tick-box in a product the firm already licenses. The investment is not lost because the project failed. It is lost because the project succeeded too slowly, against a depreciation schedule that was never written into the business case, because nobody thought to ask how fast the ground was moving.

This has a consequence that runs counter to nearly every large programme currently running. When the underlying technology depreciates this fast, only cases with a near-term, legible return survive the arithmetic. A long, architecturally heroic deployment justified by benefits arriving in year three is not a bold bet. It is a bet against the clock, and the clock has been winning.

VIII. In which we finally go looking for the money

So much for the walls. Now for the direction.

The correction is not a better method for scoring use cases. Every consultancy has one of those, and they are all fine. The correction is to reverse the direction of travel entirely, so that the choice of tool becomes the last question instead of the first.

Where, then, does one start? With money, money moves in exactly two places. I have looked for a third for many years and have not found one.

The first is to sell more. This requires demand. Without it, higher productivity produces idle capacity, and idle capacity is not an asset. It is a cost with a nice name.

The second is to remove a cost that is genuinely being paid. A contractor's invoice was cancelled. A licence dropped. A hire not made. This channel needs no demand at all, and I will tell you a secret: it is where most of the real return on corporate AI currently sits, although nobody builds a slide deck around it, because "we cancelled a contractor" does not photograph well at a conference. It has its own conditions. Somebody must have the authority and the will to actually remove the cost, and the removal must remain in place. Freed hours that remain inside the same headcount, or drift back in six months, are not a saving. They are a rounding error with a sponsor.

And here I must say something that sounds obvious and is disbelieved by almost every transformation programme I have ever seen. A process should not be the most productive process available. It should be the process best matched to the market it serves.

The Japanese worked this out on the factory floor fifty years ago. Toyota ranked overproduction the worst of the seven wastes, worse than defects, worse than waiting, because it burns real resources now to make something that may never be sold, and because it hides every other problem in the system behind an impressive-looking number. If you raise your throughput in a flat market, you have not improved the firm. You have converted cash into unsold capability and called it progress.

The Office for National Statistics has, unintentionally, measured this failing at the national scale. Three-quarters of AI-using businesses report productivity gains. Around 12 per cent report revenue growth. The gap between those two numbers is the entire subject of this essay. The productivity is real. It has nowhere to go.

I have heard the same sentence, in slightly different words, from more process owners than I can count, and it ended more conversations than any other. "Why would I change anything? I can already meet the demand I've got, and I can't see any new demand coming." That is not conservatism. It is the correct question, asked before the technology question, and a tool-first search never comes close to it.

IX. In which it is explained that an agent is not an employee

There is, of course, another route to the money, and every vendor will show it to you on slide four. It is called the "digital workforce." Replace the people, keep the process, bank the difference. It has a wonderful simplicity, and it fails, and the reason it fails has nothing to do with sentiment and everything to do with what an employee actually is.

Call a piece of software an employee, and you silently import two centuries of management practice, all of it built on properties the software does not have. Employees get tired, which limits how much damage they can do in an afternoon. They fear consequences, which makes them careful. They learn from their mistakes overnight, without a retraining budget. Their errors are largely uncorrelated: two analysts are rarely wrong in the same way at the same moment, which is why we employ two. And when an employee acts, a legal person is attached to the action, which is a great comfort to lawyers.

An agent has none of these. Nothing tires it. Nothing frightens it. Between deployments, it learns nothing on its own, contrary to what the brochure implies. Its errors are correlated with its own previous outputs and with those of every other agent in the world built on the same foundation model. And when it acts, the question of who is accountable is answered by an architecture, or by nobody.

Three things follow, and I have yet to see a deployment framework that asks about any of them.

The first is amplification. Human processes have natural damping. Handovers, approvals, a colleague leaning over and saying, "Are you sure about that?"—all of these absorb a little of an error's energy before it travels. We call this friction and spend a great deal of money trying to remove it, without noticing that it is doing a second, load-bearing job. An agent's loop has no such friction. A wrong result becomes the instruction for the next decision at machine speed, and errors in such a loop do not get absorbed. They reinforce, as any undamped feedback loop does.

The second is entropy. Every agent is probabilistic at heart, and a production agent is not one model but a small committee of them, checking, routing and scoring one another, each adding a little randomness of its own. The question for the firm is not "how accurate is the model?" but "how much added noise can our planning absorb before the forecasts become decorative?" I call this an entropy budget. Nobody has one.

The third is coupling. When an entire industry buys the same models, tuned by the same consultancies to the same best practices, the industry does not become more diverse. It synchronises. Nominally independent firms begin making the same mistakes at the same moment, and in complex systems, correlated errors do not cancel out; they compound. Finance ran this experiment in 2010 and called it the Flash Crash.

So "replace the headcount with agents" is not a cost decision. It is a decision to run the firm on a new kind of participant, under governance designed for the old kind. And there is a particular cruelty in it: cut the experts to bank the savings, and you have also removed the only people who could have taught the system anything, in exchange for a machine that will, from that day forward, get slowly worse.

The managing director, with his ten interns, had understood all this. He lacked the jargon, which I have always thought is the best way to understand anything.

X. In which waiting is considered and rejected

At this point, a certain kind of reader, and I have been that reader, will say: this is all very well, but it is early. Every great technology has looked like this at the start.

It is a good objection and deserves a proper answer, and the proper answer is electricity.

Electric motors were available to factories from the 1880s. The productivity statistics did not change for forty years. The motors worked perfectly well. What was missing was everything around them. Factories had been built around a single great steam engine, with every machine chained to a central shaft by belts, and the first thing manufacturers did with electricity was to unbolt the steam engine and bolt an electric motor to the same shaft. The productivity gain arrived only when a generation of engineers, most of them now dead and none of them famous, rebuilt the factory horizontally, with a small motor on every machine, arranged around the flow of the work rather than around the source of the power.

So yes, it is early. But notice what the objection actually says. It says the gain came when the organisation was rebuilt around what it was trying to make, rather than being equipped with the new engine. "It is early" is an argument for changing the firm's architecture. It is not, and never was, an argument for buying more pilots and waiting.

Nor is waiting available, in any case. The competence that matters here accumulates only by attempt. A firm three or four honest attempts at this know which of its processes can be described and which cannot, which data its work fails to produce, where its real constraint lies, and what its people actually do when the machine is wrong. None of that arrives by reading case studies, and none of it can be bought when the market turns. Whoever waits for the technology to settle will discover that settling was never the hard part.

So the question is not whether to try. The question is what each attempt buys, and what survives when it fails, because most of them will.

XI. The instruments, offered without further anecdote

I promised to come to what one might actually do, and I have made you wait long enough. What follows is plainer than what went before, because it is meant to be used rather than read, and I would rather you took it into a meeting than admired it.

Two situations, two tools. The first is for a firm that has no strategy yet. The second is for the projects already running, which is most firms, and it is the one worth an afternoon.

First, an honesty exercise

Every AI programme has a driver, which is why it actually started, and a stated goal, which is what the slide says. They are seldom the same thing, and the distance between them decides what kind of spending this really is.

Why it started	What the slide says	What it actually is
The board asked; a competitor issued a press release	"We are becoming an AI-first company"	Narrative spending: legitimacy and visibility, not return
Fear of falling behind; nobody wants to be the one who missed it	"Efficiency and cost reduction"	Defensive spending: pays only if a specific, named loss is actually prevented
Staff are already using AI in secret; something might leak	"Governance and responsible AI"	Governance spending: risk containment, never a source of profit
Someone wants to own a new product	"New revenue"	Product R&D: pays only if a customer is shown to be willing to pay
A sponsor saw a demo and was impressed	"Innovation"	Discovery R&D: buys knowledge and a stop-or-go decision
A named, measured constraint on a named revenue or cost line	"Scale a proven case"	Operating investment: the only row that has earned a number for ROI

Nearly every programme I have seen sits in one of the first five rows and is funded as though it sat in the sixth. Naming the row correctly costs nothing and changes everything that follows.

Six questions, in this order, for a firm starting out

The order is the method. Each question is worth asking only if the previous one has an answer.

1. Where does the money move? Name the channel: additional volume the market will buy, revenue demonstrably defended, or a cost genuinely being paid that can be removed. Evidence is a pipeline, churn data, a contract, a supplier's invoice, and a workforce plan. "Efficiency" is not a channel.

2. What is the constraint? Not which task looks automatable. Which step actually limits throughput, or which capability actually limits the sale? If you cannot name it, you are not ready to pick anything.

3. Will the gain stay with us? If every competitor buys the same tool next quarter, what is left? Value stays only where something is hard to copy: data rights, distribution, depth of integration, liability cover, regulatory position, domain know-how. Otherwise, the savings pass straight through to customers as a lower price, and you have paid for an industry-wide upgrade.

4. Why does this need AI? Priced against simplification, integration, better search, plain rules, and conventional machine learning. Not against doing it by hand. Manual work is the straw man that has justified more failed automation than any other habit in enterprise IT.

5. What is the target workflow, and what data does it emit? Roles, exceptions, escalation, thresholds, accountability, and the record the process must now produce so that the system can improve. Designed before tooling. A business owner signs up to accept it in advance, provided the agreed-upon conditions are met.

6. Now, and only now: which instrument? Model, vendor, build or buy. The last question and the cheapest one. Currently, the first question is asked in most organisations.

Most candidates die at questions one or two, before anyone has spoken to a vendor. That is not a failure of the method. That is the method. The cheapest place to kill a use case is before it becomes a pilot.

Nine questions for what is already running

Run this against every AI project in flight. It takes an afternoon, needs no new analysis, and requires only honest answers. Each question comes with a named failure, which is what makes it difficult to argue with in the room.

1. Who loses money if the benefit never appears? A named business owner with a number in their objectives. No name: it is a demonstration, not a project.

2. Which line of the P&L moves, and by what mechanism? Point to the invoice, the headcount plan, and the revenue line. "Productivity" or "efficiency": no channel has been identified.

3. Is the target step the binding constraint? No: the gain is capped at a small amount and may be negative.

4. What non-AI alternative was priced? Only "how we do it manually today": straw-man comparator.

5. If a competitor buys the same tool next quarter, what remains? Nothing specific: the value is real but not yours.

6. Was the baseline measured before the project began? Measured afterwards, or estimated: no return can ever be proven, only narrated.

7. Does a target workflow exist, with exceptions, review and accountability, accepted in advance by the business? "We'll work that out after the pilot": the pilot cannot convert, whatever it shows.

8. After go-live, does the process produce the data needed to improve the system? No: one round of value, then slow decay while the costs stay flat.

9. Does the benefit arrive before the technology beneath it turns over? Year three: you are betting against the clock.

And how to read the result, because the pattern of failure tells you the remedy, which is why this is better than a scorecard.

• Fails 2 or 6: this is not an investment. Reclassify it today as discovery R&D, with a budget cap, a time limit and a stop rule, or stop it. It cannot carry a return figure, and giving it one is what destroys a programme's credibility later.

  
  

• Fails 3 or 5: the value is real, but you have aimed at the wrong place or cannot hold on to it. Re-aim; do not cancel. The team and the learning are sound.

  
  

• Fails 7 or 8: the value is real, and you cannot operate or sustain it. The fix is design work, not more model work, and no further pilot will produce it.

  
  

• Fails 9: shorten it or kill it. There is no third option.

  
  

• Passes all nine: rare. Fund it properly and stop diluting it across the portfolio.

Expect the number of survivors to be small. That is the finding, not a failure of the exercise. It turns an undifferentiated spend into a handful of things you can actually defend.

What to do with the ones you stop

Harvest them. Every attempt, including the failures, should leave something behind: a process now described, a constraint located and measured, a workflow that now produces usable data, a real answer from a real customer about whether they would pay. These assets compound across attempts and do not depreciate at the rate of the model that produced them. They are also the one thing a competitor cannot buy with a cheque.

A stopped project that leaves these behind was cheap. A running project that produces none of them is expensive on any budget.

The strategy document itself

An AI Integration strategy is not a ranked list of use cases. That is a menu of ways to spend money, sorted by the confidence of whoever estimated the benefit. The real thing fits on a page and has three sections.

Where our money comes from and what constrains it. Written in the language of the business, not of technology. If this section is hard to write, you have found the real programme, not an AI programme.

What we have learned and what we now hold. The assets from every attempt so far, including the failed ones. This section shows whether the firm is compounding or merely spending.

What we are currently paying to find out. The live discovery R&D, with its cap, its horizon and its stop rules, is named as such and not disguised as investment.

If those three sections can be written honestly, the use cases will select themselves, and there will be fewer of them than anyone hoped.

XII. In which Harris is left with the last word

I told Harris most of this over the same dinner, at rather greater length, and he listened with the patience of a man who has been given advice by architects before.

When I had finished, he said, "So what you're telling me is that the board asked the wrong question."

I said that was roughly it.

"And that the right question is where the money is."

I said it was.

"Which is what I do all day," said Harris, "and which nobody has asked me about in eleven years."

I have no answer to that, and I have stopped looking for one. But I will say this. The bubble will keep making its offer through every door and window it has, for as long as the money behind it needs someone to buy. You cannot switch that off, and you probably should not try. What you control is the order in which you search.

An AI-native enterprise is not one that has found more places to put AI. It is one that knows precisely where its money comes from, enough to recognise the rare occasions when AI is the answer.

Find the money. Then ask what it needs.