Mathew McKie

If we tackle a similar Generative AI (GenAI) problem tomorrow, will it be easier because of what we did today?

That is a different question from asking how much GenAI an organisation has deployed.

GenAI and the agentic systems being built around it are spreading through businesses quickly. In IBM’s 2026 study of 2,000 technology executives, 70% said teams across their businesses were deploying technology faster than IT could track. An EY survey of US senior leaders found that 82% of those whose organisations were investing in AI were concerned about token usage and its cost.

Those figures tell us something about how quickly GenAI is spreading and how visible its consumption costs are. They tell us much less about whether all this activity is making the organisation more productive or creating more value.

An organisation can accumulate GenAI products, spend and use cases without building much of the capability needed to turn them into either.

That is where the interesting problem begins.

The model may be shared. The organisation is not.

GenAI is different from many previous enterprise technologies because the same underlying models can be applied across an unusually wide range of problems. The engineer, lawyer, finance team and customer-service operation can all use versions of the same models, often without waiting for a large central technology programme.

That flexibility is part of its appeal, but it can disguise what actually creates value.

The model may be shared. The organisational context is not.

A model does not arrive knowing why a field in a legacy system means something different from its label, which process exceptions matter, what evidence will satisfy risk and security, which integration behaves strangely, how decisions are really made or what users will trust.

Those things have to be learned.

If that learning survives, the next team can start somewhere better. It may inherit understood data, a working integration, an evaluation method that has already been tested, approval precedent and people who know which parts of the problem are difficult.

But not everything is equally worth preserving. Code, prompts and tooling may lose value quickly as models, products and standards improve. Understanding your own data, operating exceptions, controls, approval evidence and where GenAI can safely be trusted may last much longer. Some capability compounds; some expires.

There is a structural requirement behind this. Learning compounds only if the system has somewhere for it to persist. For the organisation, that might mean people, ownership, routines, decision precedent and shared information structures. For a GenAI or agentic system, it might mean persistent context, understood semantics, evaluation evidence, memory and reusable tools. In both cases, experience alone is not enough. What matters is whether yesterday’s experience changes tomorrow’s starting point.

The economics of the next opportunity have changed because the previous one happened.

But only if enough of what was learned survives.

The capability has no natural buyer

Imagine three teams, six months apart, finding similar opportunities to extract information from complex documents.

The first solves its problem. It gets access to the information, works out the integration, develops a way of evaluating the output, gets through security and risk and puts the solution into use.

The second encounters something similar. Some of the first team’s work could help, but it was built around another deadline, budget and immediate need. Making it useful beyond that original problem requires additional work, and that work does relatively little for the second team’s own business case.

So the second team takes the quickest route to its outcome.

By the third use case, the organisation has paid several times to discover that it had a reusable problem.

Nobody behaved irrationally. Each team made a sensible decision against the budget, outcome and timescale it actually owned.

The failure sits above them.

This is the same organisational problem I explored in The (Gen) AI Transformation Paradox. There, costs, benefits, authority and accountability could sit in different parts of the organisation. Here they can also sit in different periods of time.

Long-term capability creates value across initiatives and over years, while organisations commonly allocate money through projects, functions and annual budgets. The person being asked to spend more today is rarely the person who captures all of the benefit tomorrow.

I think of that additional investment as the reuse premium: the cost of taking something that solves today’s problem and making it improve the economics of the problems that follow.

If every initiative is judged mainly on its own return, nobody has much reason to volunteer to pay it.

An organisation can therefore make entirely rational investment decisions one project at a time and still systematically prevent itself from developing the capability that would improve the economics of the portfolio.

Why the early economics can mislead

Now imagine that organisational capability for GenAI does not improve evenly.

At first, progress is expensive and difficult to see. Teams are still discovering how to prepare information, connect systems, test uncertain outputs, get approval, redesign work and decide where GenAI can be trusted. The cost arrives now, while much of the learning becomes valuable only if similar opportunities appear later.

Eventually, enough of those problems may have been solved that a new deployment starts somewhere different. Integrations already exist. Important data is understood. Evaluation has precedent. Approval is based on evidence rather than theory. People know what works.

The next deployment becomes cheaper, faster or safer. That makes another use case worthwhile which previously was not. The new deployment creates more experience, which can make another opportunity viable.

The important point is that the economics do not have to improve smoothly. Capability can accumulate for some time without dramatically changing the business case. Then enough recurring cost, effort or risk is removed for previously unattractive opportunities to become viable.

There is precedent for this kind of delayed payoff. Brynjolfsson, Rock and Syverson’s work on the productivity J-curve shows how general-purpose technologies can require substantial complementary investment in processes, skills, business models and other intangible assets before much of the productivity benefit becomes visible.

That creates an uncomfortable possibility:

An organisation can rationally reject a series of weak GenAI business cases when each is assessed on its standalone economics and, in doing so, prevent itself from developing capability that would have made later business cases stronger.

The first projects look expensive because the organisation is still learning. The rational response is to demand better standalone returns, constrain investment and make each new initiative carry its own costs. The problem is that this treats interdependent investments as though their economics were independent: value created for future deployments is easy to exclude from today’s business case because nobody can yet point to the project that will claim it.

But if some of those costs keep recurring because nobody has been funded to remove them, the investment model is helping create the weak economics that appear to justify the investment model.

The organisation can stop just when it looks least impressive.

The dilemma cuts both ways

The answer is not to build everything for reuse.

Invest too little and shared capability never forms. Invest too early and the organisation builds expensive common services for demand that never arrives.

That is the capability compounding dilemma.

We have seen the second failure before. Shared platforms get built for hypothetical customers. Architecture becomes an objective rather than an answer. Reuse costs more than rebuilding.

So there are two different levels of investment.

The first is basic reuse hygiene: keep useful evaluation evidence, record what was learned about an integration, preserve important approval decisions and make ownership clear. That should be normal delivery — the price of not deliberately forgetting.

Because the incentive problem exists from the first deployment, this cannot depend on whether an individual project manager happens to value future reuse.

The second is the reuse premium itself. Once repeated demand becomes visible, somebody has to decide whether it is worth rebuilding an integration for wider use, creating a shared service, improving common data or turning local learning into something that changes the starting point for subsequent work. The case is strongest where the capability is likely to persist; there is little value in paying today to preserve something the market is likely to make obsolete tomorrow.

A second similar request might be enough to ask the question. It is not enough by itself to determine the answer.

What actually compounds?

The important idea is not simply that reuse saves money. It is that accumulated capability can change which opportunities are economically possible.

Suppose a GenAI use case would cost more to implement than the value it is expected to create. It should be rejected.

Now suppose earlier deployments have already paid for much of the recurring work around data, integration, evaluation and approval.

The same opportunity may now clear the organisation’s investment threshold.

Nothing about the underlying model had to improve. The organisation changed.

That is where reuse becomes more than efficiency. Capability created by earlier work has made an opportunity viable that previously was not. The new deployment then creates more learning and can lower the threshold again.

This also means an apparently successful GenAI project can deliver its business case and leave almost nothing behind, while another with mediocre standalone economics can solve problems that materially improve everything that follows.

We rarely evaluate them that way.

And this is where the strategic consequence gets more interesting.

Competitors can buy the same models, use the same consultants, acquire similar software and hire experienced people. So accumulated capability is not automatically an impenetrable moat.

But they cannot instantly acquire everything your organisation has learned about its own information, systems, controls, risks and operating environment, or the evidence that has built confidence in where GenAI can safely be relied upon. Some of that can be transferred; some has to be learned by doing.

If one organisation reaches that threshold first, the difference does not have to remain constant. It can pursue opportunities the other still cannot justify. Those additional deployments create further knowledge, which can make still more opportunities viable.

The underlying models may be available to both. Their ability to exploit them need not be.

Why GenAI makes the funding problem harder

None of this is unique to GenAI. Organisations have faced similar problems with data, platforms and other shared capabilities for decades.

GenAI makes the problem harder because potential applications can spread faster than the organisational capability needed to exploit them.

McKinsey describes business units buying GenAI capabilities independently, employees creating GenAI workflows outside central IT, and spending spreading across model vendors, cloud providers, software platforms and experimentation environments. Its 2026 work argues that many organisations lack the visibility and controls required even to manage this consumption effectively.

That helps explain why token costs are becoming such a prominent concern. Tokens and vendor invoices are visible immediately. The value of solving an integration once rather than five times, retaining approval precedent or learning where GenAI can safely be trusted is much harder to assign to one budget.

We may become highly disciplined about the cost of consuming intelligence while remaining surprisingly poor at valuing the capability being created around it.

How would you know?

The test should be practical.

For similar deployments, is the time required falling? Are fewer days needed from scarce specialists? Is less approval work being repeated? Does the next team begin with more of the relevant data, integration and evaluation already understood?

Most importantly, are there opportunities the organisation once rejected that now make economic sense because of capabilities created elsewhere?

Models becoming cheaper and better cannot answer those questions, because competitors receive much of the same benefit. What matters is what is becoming easier because your organisation has done this before.

If nothing meaningful changes, the organisation may be accumulating activity rather than capability.

If cost, time and risk keep falling and previously unattractive opportunities become viable, capability is beginning to compound.

Who is investing for tomorrow?

That leaves an organisational-design question.

Someone needs enough visibility to see recurring problems across individual investments, enough authority to act when those patterns appear and a mandate that extends beyond the return on one project.

That does not automatically mean a large central GenAI team, a single platform or even internal ownership. Different organisations will sensibly make different choices.

But somebody has to be accountable for the economics across time.

Otherwise every team can make the right decision for the initiative in front of it while nobody is responsible for improving the starting point of the initiative that comes next.

Which brings us back to the question at the beginning:

If we tackle a similar GenAI problem tomorrow, will it be easier because of what we did today?

If the answer repeatedly remains no, the organisation may have more GenAI without becoming much better at using it.

If the answer increasingly becomes yes, the consequence can go well beyond efficiency. Previously unattractive opportunities become worthwhile, those deployments create further knowledge and the organisation can begin to move down an economic path that competitors cannot reproduce simply by buying the same model.

That is why the dilemma is so difficult to resolve: the investment that makes tomorrow easier is made today, while much of its value belongs to teams, projects and opportunities that do not yet exist.

If nobody has a mandate to invest across that boundary, the organisation should not be surprised when the capability never compounds.