Software used to be a fixed cost. You bought a number of licences, you knew what the year looked like, and the finance conversation was over until renewal. Agentic AI breaks that, because the cost now moves with how much work the system does, and how much work it does depends on how well it is adopted.

That is a genuinely different animal, and most business cases have not caught up. They were written in the old shape: a fixed investment, a projected saving, a payback period. Then the thing goes live, consumption behaves in a way nobody modelled, and the conversation with finance restarts from a worse position than it began.

There is a related problem that research published this month puts numbers on. Gartner surveyed 204 finance leaders in March 2026 and found that forty five per cent of finance AI investments lean towards productivity, while only twenty per cent lean towards decision quality. Functions that invested in initiatives creating new value propositions, products, or markets were more than twice as likely to report high realised value. Gartner’s own reading is that boards care about growth and better decisions, while teams are measuring hours saved.

So the problem is not that organisations are failing to measure. It is that they picked the metric before they understood the cost shape, and both were decided in a room that no longer exists.

The reflex, when you realise the forecast is wrong, is to commission a better forecast. In my experience that is the wrong move, because the six month modelling exercise arrives after every decision it was meant to inform.

A rough estimate grounded in reality moves faster than a perfect one you are still waiting for, and it is usually close enough for the decisions that actually matter. What it needs is not more data. It needs the right use cases and honest assumptions about them.

For platform work, a usable estimate rests on a small number of inputs. This is the shape we use, and none of it requires data you do not already have.

Those four convert into an effort figure and a capacity figure, and from there into something you can put in front of a chief financial officer. It takes an afternoon.

Here is the honest limitation of the model I just described. Licence counts and ticket volumes tell you how much human work a platform generates. They tell you almost nothing about how much work an agent will do, because an agent’s consumption is driven by how often it is invoked, how much context it needs each time, and how many attempts it takes to finish the job.

The architectural side of this question, which model you run and what it costs per unit of work, is a separate argument and my colleague Jannis has made it properly elsewhere. My concern is narrower and more operational: whoever signed the business case is going to be asked whether it still holds, and someone needs to be able to answer.

That is what the shift in how these services are bought is really about. For small and mid-market platforms, a customer buys a defined number of hours a month, and those hours cover more than break-fix: the roadmap, enhancements, releases, micro-projects, and the governance around them. For enterprise we run an operate and run model, with a squad working inside the customer's own team, a monthly figure they know for the next twelve months, and us accountable for the outcome rather than for the activity. Anything genuinely outside that framework is a separate conversation, and saying so up front is the honest part. 

Structure it that way and the ordinary month is covered while the exceptional month is named. The forecast then only has to be roughly right about the ordinary month, which is a much easier thing to be right about. 

The second thing that has to exist before you scale is a definition of what good looks like, and this is where most organisations come unstuck for a reason that is not technical.

The definition has to be written before the system exists, by the people who will subsequently be measured against it. That is an uncomfortable ask. It is much easier to deploy first and decide what success looked like afterwards, which is how you end up with a capable system that nobody fully trusts and nobody can defend at the next budget cycle.

Organisations that define it up front see stronger adoption, faster value, and more confident buy-in across the board. Not because the definition is magic, but because the act of writing it down forces the argument about what the thing is for while that argument is still cheap to have.

Keep the definition non-financial and keep it small. Three signals a business owner can read without translation are worth more than a dashboard nobody opens.

There is a version of this work that leaves the client weaker, and it is worth naming because it is easy to fall into. A partner learns the platform, absorbs how the business uses it, delivers, and leaves with all of that in their heads. The reporting looks fine. The customer is more dependent at the end than they were at the start. 

We are not there to replace the internal capability of customers. We are there to augment it. We sit alongside the team, expand what it can do, and take the mundane work off it, so the people who understand the business can spend their time on the bigger picture and on where the platform should go next. And we build the knowledge together, so it does not feel like we are taking the knowledge and leaving. 

That is also the practical answer to the capability question a consumption model raises. Hiring in-house buys one skill and one resource. When the roadmap moves, that is another hire and another wait. A run arrangement written properly already has the range in it, and reaching for a different skill does not mean re-contracting to get it. 

Resource augmentation fills capacity. Running the function is a different job, and the difference shows up in month six rather than week one. 

The contract matters on day one. After that it goes in the bottom drawer, and the relationship and the outcomes are what get managed. 

Our platform success practice runs the function after go-live, which is when the consumption question becomes real. Four things we put in place:

1. Size it in an afternoon. Product mix, user base split internal and external, actual volume, and specialist load. Honest assumptions beat a six-month model.

2. Write the definition of good before the build. Three non-financial signals a business owner can read without translation, agreed by the people who will be measured on them.

3. Transfer the knowledge in four weeks. The team running the platform should know it as well as the team that built it.

4. Ship an improvement in week five. Early evidence that the operating model works, rather than a promise that it will.

Resource augmentation fills capacity. Running the function is a different job, and the difference shows up in month six.