BCG published two articles on what AI actually costs a company. Joppe Bijlsma, Djon Kleine, Filippo Scognamiglio.

Here's what they say, and where I think it stops.

What they say

Software has left the subscription era. AI usage meters replaced the flat license, and the meter runs superlinearly — an agentic session that feels twice as long can bill four times as much, because each reasoning loop resubmits the whole growing context.

Those charges don't belong on one line. Tokens that build reusable capability are capex. Tokens running internal work are opex. Tokens burned inside a product a customer touches are COGS, and they hit gross margin directly.

So the number to manage isn't the bill. It's cost per outcome — per resolved ticket, per qualified lead, per analysis someone actually used. Their fixes: stop sending deterministic work to a model, route easy work to cheaper models, cache what you reuse, assign every workflow an owner and a P&L line, train people to ask for less.

They identify the right problem and they get the risk right. Their sharpest line is that clamping down on usage starves the high-return work and pushes the company toward labor-substitution cases — the easiest to measure, the smallest in payoff.

Where it stops

They name the hard part correctly: you need cost per outcome. What I'd add is why that part is hard, because it isn't a reporting problem.

Cost per outcome is a ratio, and only one side of it is solid.

The cost side is exact. Every token, every call, timestamped, attributable to a workflow, on the invoice this month.

The outcome side isn't blank — companies watch the KPIs they already have. But those move for a hundred reasons, and pulling one workflow's contribution out of them is a signal-to-noise problem.

The metrics that would close the loop are the hard ones. Is revenue incremental, or would it have happened anyway? Is a lead qualified when marketing hands it over, or when it closes three months from now? Is a retained customer saved, or just delayed by a quarter?

Every one of those definitions is defensible. Every one of them also takes time to settle — the answer arrives after the period closes, and by then several other things have changed too. Which is the second problem: a lagged result is hard to attribute back to the decision that caused it.

Those definitions can be built. They take iteration, and live results to validate against. That takes quarters.

So the cost side has a precise number now, and the outcome side has an approximate one that gets sharp later.

That's the shift, and it isn't that AI got expensive. It's that AI decisions now get made with an exact cost against an unsettled return — and an exact cost number beats an unsettled one in every meeting, regardless of which one matters more.

Worth saying plainly: exact is not the same as complete. A token bill measures one thing precisely — what it took to run that workflow. It has no opinion on whether the workflow should exist. On an invoice, a well-instrumented cost centre and a workflow that creates real value look identical.

Which lever moves first

Look at their fixes again. Routing, caching, governance, training — each one requires knowing what a good outcome is before you can tell whether it worked.

Cutting headcount doesn't. The saving is a salary line: exact, landing this quarter, requiring no new definition of anything.

You can remove a role this quarter with authority you already have. You cannot get finance, operations, the executive team and the board to agree this quarter on what counts as incremental revenue — and those are exactly the people who can quantify, who understand risk, and who hold the decision.

So headcount moves first. Not because it's the strongest lever — because it's the only one that doesn't have to wait for the measurement to mature.

And it's the only lever you can't undo

Get routing wrong and you change a setting back. The cost of being wrong is a month of overspending.

Cut a team and the capability doesn't return at the price you sold it for. Rebuilding takes years, and most of what left was never in the documentation: why that metric was defined the way it was, which exception matters, who to call when the number looks wrong. The people who could have written the outcome definitions are usually the same people being removed for lack of one.

Meanwhile the replacement is metered. Per-token prices keep falling, but nobody buys last year's capability at last year's price while a competitor buys this year's. Cheaper units don't guarantee a cheaper outcome.

So it's a long-term bet on someone else's future pricing, paid for by giving up the ability to change your mind — and it gets placed in the month when you know the least.

The real question

Sometimes that's the right bet. The question is whether it was made on purpose, or by default, because it was the only lever that would move.

I hit a smaller version of this a couple of weeks ago. Building a meeting cost calculator, I deleted the "reduce attendance" suggestion entirely. A cost number makes removing people look like arithmetic, and the people cheapest to remove are usually the ones there to learn.

The easiest thing to count becomes the thing that gets cut.

Real question, for anyone further along than me: has your team agreed on what an outcome is? Or is it still getting settled one invoice at a time?

Back to the build.