AI Compute Intensity Has a Second Variable
BCG’s recent report on AI and competitive advantage identifies compute intensity as one of five factors that determine how AI value moves through a sector, and singles it out as the genuinely new feature of this cycle. Their comparison is electricity at the start of the twentieth century, when utilities became a fixed intermediary inside every industrial process rather than a supplier standing beside it. Frontier compute now plays a similar role, a permanent claimant on the output of every sector that adopts it. In their framework, compute intensity governs how much value leaks out of a sector to this new layer, and the assumption underneath that number is straightforward: leakage tracks usage. Burn more compute, more value moves to the layer supplying it. Fair enough, at the level they are writing at.
It holds less well once you stop comparing sectors and start comparing two companies in the same one, spending roughly the same amount against the same models. I have sat in enough of these architecture reviews to know usage numbers get presented like they explain the whole picture, and at some point they just stop doing that. Two teams can burn identical compute and end up somewhere completely different a year later, and usage was never going to tell you why.
Going deep on a single frontier model’s capabilities, rather than staying shallow across several, is often exactly the right call for a technology organization trying to build genuinely differentiated products. Worth saying plainly, because what follows can read as an argument against depth if you skim it. It isn’t. The organizations building the most capable agentic workflows today are willing to build against a specific model’s particular strengths instead of the generic lowest common denominator across providers, and that is what produces faster iteration and workflows a shallower integration simply could not support.
What varies between two similarly spending companies is not how deep the integration goes. It is how deliberately that depth was chosen, and how well the organization understands what it has actually built. One company goes deep because a careful architecture decision concluded the capability gain was worth the commitment, and it keeps a working sense of what changing course would cost. The other gets to the same depth by accretion. A hundred small engineering choices made under deadline pressure, each one reasonable on its own, nobody adding them up. Both spend the same. Both ship equally capable products this year. Only one of them could tell you, without checking, what they’d actually built.
Switching position is the variable a leader can actually influence
The compute intensity variable is really compute intensity multiplied by how well the organization understands its own switching position. The second term is the one a technology leader actually has influence over, which is probably why it gets less airtime than the first. Usage is mostly a function of ambition and product surface area, and trying to shrink it is rarely the right move. Understanding the switching position is different. It’s a function of practice, something you build regardless of how deep you’ve gone on any given model.
Which changes what the leadership conversation should actually be about. “How much are we spending on compute” and even “should we go deeper on this model” only answer half. The question that matters more is whether the organization can say, right now, with confidence, what a change in strategy would cost to execute, and whether anyone has checked that number lately or is just assuming it still holds.
A few habits keep that second term visible
None of them require pulling back from depth.
Document the specific capabilities a workflow is actually built on, and be honest about which of them are load bearing. Not just the provider, the particular strengths underneath it: a certain context handling approach, a tool use pattern, a specific agentic behavior. Take one of those away and the workflow doesn’t degrade gracefully. It stops working. This is closer to an engineering inventory than a governance exercise, and most teams building genuinely advanced workflows already have the technical grasp to produce one. What’s usually missing is somebody bothering to write it down in a single place.
Periodically run the workload against an alternative too, and not because a switch is on the table. An assumption nobody has tested recently isn’t really known, it’s just remembered, and those are not the same thing. Same discipline most organizations already apply to disaster recovery without thinking twice about it. Tested capability, not trusted capability.
And separate what is genuinely proprietary, the data, the fine tuning, the accumulated context that belongs to the organization, from what is simply a well built integration with a provider’s current capabilities. Both matter. Only the first is a lasting advantage independent of any single relationship, and knowing the difference is what lets a leadership team make the next deep integration decision as deliberately as the first one, rather than just deeper.
Unmeasured depth is the expensive kind
Two organizations spending identically on frontier compute over the next few years will end up in very different places, and the gap won’t show up on either company’s compute bill. It’ll show up in how quickly, and how confidently, each one can answer a direct question about its own architecture when a board member asks it, or an auditor, or the market itself. BCG is right that compute intensity determines how much value a sector gives up. What the organizations that keep the most of it will have in common is not restraint. It’s that they went deep on purpose, with a clear account of what they built, instead of arriving there by accumulation while nobody was counting.
Reference: https://www.bcg.com/publications/2026/which-companies-capture-value-from-ai
