Most AI programs report purchases and call them capabilities. A story about a board meeting, the test that tells the two apart, and why passing it is only half the job.
Most AI programs report purchases and call them capabilities. The difference decides whether anything survives the vendor, the quarter, or the strategy.
Full argument below · about 10 minutes
The slide is good, which is what makes the first question land the way it does.
It is a Series A company, forty two people, eight months into taking agents seriously. Support resolves a ticket in a bit over half the time it used to take. Engineering merges more than it did in January with the same eleven people. Two sales reps now cover the research and follow up that used to occupy most of a third. Every number is real, and the founder has been looking forward to putting it up.
The board member who says the least waits until he has finished.
What critical capabilities did we buy with that money?
He starts listing the stack. A model provider, an agent framework, an evaluation harness, two integrations that took a quarter. She stops him, not unkindly. Those are purchases. A capability is something this company can do now that it could not do in January, and would still be able to do on Monday if the vendor went out of business on Friday. Half the room writes that down.
And how are they making us win?
The honest answer, which nobody offers, is that they are not making the company win anything yet. They are making it cheaper to run. That is a real and useful thing, and it is a different claim, because any competitor can match it inside a quarter by signing the same order form. Cheaper is not a position. It is a number that moves until everybody has moved it.
Where do they let us play that we could not play before?
There is a good answer to this one, and it is sitting in the room unsaid. At the new cost to serve, the mid market accounts the company has been declining for two years are viable, and that is a named segment with a known size and a sales cycle somebody could forecast. Nobody offers it, because nobody has connected eight months of engineering work to the boundary of the market it quietly moved.
Nobody here is being unreasonable, and the team has executed well. The difficulty is that the investment was run as a technology program and is now being examined as a strategic one, and those are different objects. A technology program has a stack, a delivery date and a throughput number. A strategy has a piece of ground it has chosen, a reason it can hold that ground, and a list of things it has decided not to do. Eight months in, the first exists in considerable detail. The second has never been written down.
•••
Nobody in that room was being unreasonable, and the program had done what it was chartered to do. The difficulty is that the charter described a deployment and the board was asking about a strategy, and the gap between those two things is where most of the money goes.
The distinction sounds pedantic right up until you try to use it, at which point it does most of the work.
A purchase is an entry on a schedule. It has a vendor, a renewal date, and an owner somewhere in procurement. A model provider is a purchase. So are an agent framework, an evaluation harness, an implementation partner, a training program and a set of licences, and a company can assemble an impressive quantity of them in eighteen months without becoming able to do a single thing it could not do before.
A capability is different in kind rather than in degree. It is something the company can do, repeatedly and at scale, for somebody outside the company, that it could not do previously. It has a name a customer would recognise. It survives the departure of whoever built it. And unlike a purchase, it is difficult to acquire quickly, which is precisely what makes it worth having.
Most programs report purchases and call them capabilities, not out of dishonesty but because purchases are what a program is set up to produce. A deployment plan has line items. It does not have a column for what the company will be able to do at the end of it, and so nobody fills one in.
There is a short way to tell the two apart, and it is worth running out loud, in the room, while people are still claiming credit.
If your principal vendor went out of business on Friday afternoon, what could you still do on Monday morning?
Not what you could eventually rebuild, given a year and a budget. What would still function on Monday, for customers, at something close to the quality you promise them now.
Run it honestly and the list comes out shorter than anybody expects, which is the point of running it. The assistant is gone. The agents are gone. The evaluation harness is gone, along with the dashboards that were the main evidence the program was working. If the answer is that operations stop, then what was built was a dependency, and it has been reported to the board for six quarters as a capability.
What tends to survive is unglamorous and worth listing precisely, because it is the actual asset. The process you redesigned before you automated it, which still works when performed by people, more slowly. The data you accumulated and cleaned, which is yours. The interfaces and the boundary you built, if you built one, which means a second supplier can be behind it by the middle of the week. And the institutional knowledge of which decisions in this business can be delegated to a machine and which cannot, which is genuinely hard to buy because the only way to acquire it is to have got it wrong a few times at your own expense.
None of those four things appear on a vendor's invoice. All four are what you would have left.
Passing the Monday test is necessary and it is not sufficient, which is where a lot of otherwise sensible programs come unstuck. It is entirely possible to build something durable, genuinely owned, technically impressive, and strategically pointless.
The second question is what the capability is for. Specifically: which piece of ground does it let us compete on, and what about it makes us hard to displace there? A capability that cannot be attached to a chosen market and a reason for winning in that market is a hobby with a budget line and an internal fan club.
Three shapes of failure show up repeatedly, and they are easy to tell apart once named. There is the capability with no ground, which is a team that has built something clever that no segment is waiting for. There is the ground with no capability, which is a company that has correctly identified where it wants to compete and has bought a subscription in the hope that this constitutes an answer. And there is the capability serving ground you have already decided to leave, which is the most expensive of the three, because everybody involved is doing good work.
The test for the second question is as blunt as the first. Name what you can do that a competitor holding an identical purchase order cannot. If the answer is a model, a framework or a vendor relationship, there is no answer, because those arrive by credit card and the order form is public. If the answer is your data, your redesigned process, your customer relationships or what your people have learned about delegating judgment, then there is something to defend and it is worth deciding how much to spend defending it.
Alignment is just those two questions being answered by the same sentence. The capability has to be one you own on Monday, and it has to be pointed at ground you have actually chosen. Programs fail the first test loudly, with an outage. They fail the second quietly, for years.
There is a second reason the cost savings play never turns into an advantage, and it is worth separating from the first. That everyone can buy the same models is obvious. What is less obvious is what happens to a company that builds itself directly on top of one of them.
Wire one provider's API through the middle of your product and your operations, let it accumulate for a year, and you have not acquired a capability. You have acquired a dependency with a seat at your strategy table. Their pricing is now your margin. Their rate limits are now your availability. Their deprecation schedule is now your roadmap. Their security posture is now the answer you give a customer's procurement team, whether or not it is the answer you would have chosen. None of those were decisions anybody made. They arrived attached to the thing that was, at the time, simply the fastest way to ship.
The failure mode here is not that the provider is bad. Most of them are very good, which is exactly why it happens. Convenience is the mechanism. Every individual integration is the reasonable call in the moment, and the aggregate is a company whose cost base, uptime and product direction are set by an organization that has never heard of it.
A company built on somebody else's inference has not chosen a technology. It has chosen a landlord.
The fix is unglamorous and far cheaper than it sounds, which is the argument for doing it at the start rather than after. Put a boundary between what the work needs and who performs the inference. Define the operation in terms of the function being carried out, classify this ticket, draft this reply, reconcile this ledger, extract these terms, and let the provider sit behind that line as an implementation detail rather than as the thing itself.
What that buys is not theoretical. It is being able to price two suppliers against each other instead of reading a letter about a change to your rate card. It is routing shallow, high volume work to something small and cheap while the genuinely hard calls go to the best model available this quarter, which is rarely the one that was best last quarter. It is running whatever touches regulated data somewhere you control while everything else stays on a hosted endpoint. It is being able to answer a question about where inference happens without the answer being a shrug.
The price of this is a few days of design up front and the discipline not to let provider-specific concepts leak upward into everything else. The price of skipping it is discovering, in the quarter when it finally matters, that the boundary has to be retrofitted through nine hundred call sites while a repricing takes effect.
This is the whole difference between a capability you rent and one you own. You will still rent the inference, and you should: training your own is a way of spending eight figures to arrive somewhere worse. What you own is the shape of the work, the data it runs on, and the standing freedom to change your mind about who supplies the engine. That is a far smaller thing than a proprietary model, and it is the part that is actually yours.
Rather than arguing about whether an investment has produced a capability, it is more useful to write down what would have to be true for the claim to hold, and then go and check. The list is short and awkwardly testable, which is the merit of it.
Six of those are matters of fact and can be settled in an afternoon. The seventh is the one that predicts whether any of it survives the next budget cycle.
•••
Back to the board meeting, because the answers were available and nobody had assembled them.
Somebody could have said: what we built is the ability to take a category of customer request from arrival to resolution in hours rather than days, at a quality our own auditors sign off on. It runs on fifteen years of our operational history and on a process we redesigned before we bought anything, and it sits behind a boundary that does not much care which supplier is on the other side, which we know because we changed one in March and nobody outside the company noticed. It lets us compete for the segment we could never serve at an acceptable margin. And what a competitor with the same purchase order cannot do is any of that, because what they can buy is the part that was never the hard part.
That answer does not require better technology than the company already had in the room eighteen months ago. It requires somebody to have decided, at the point the charter was written, that the money was buying a capability rather than a deployment, and to have been willing to say which one, out loud, before anybody knew whether it would work.
You will rent the inference, and you should. Training your own is a way of spending eight figures to arrive somewhere worse, and the part everybody can buy is improving faster than anything you could build alone.
What you own is the process you rebuilt, the data underneath it, the boundary that lets you change your mind about suppliers, and the accumulated judgment about where a machine can be trusted. That is a much smaller list than a technology strategy usually contains, and it is the only part of it that would still be there on Monday.
Talk to an advisor →