The Five Cs for Enterprise AI Decoupling
Following up on The Enterprise AI Tenant Boundary Doctrine.
The Enterprise AI Tenant Boundary Doctrine
When the CEO of the world’s most valuable enterprise software company writes a manifesto and quotes the CEO of the industry’s most controversial data platform inside it, that is not decoration. That is a coalition forming in public.
And once you do understand the dynamics behind the Enterprise AI Coalitions.
The Enterprise AI Coalitions
Yesterday, I explained and dissected to you why a coalition is forming in Enterprise AI, based on the manifesto that Microsoft’s CEO, Satya Nadella, had published.
That is how you can really grasp the Five Cs.
Control, Capability, Choice, Cost, and Compound are architecturally right. They correctly identify the load-bearing components of enterprise AI. They correctly diagnose the leaks that default configurations produce. They correctly assert that partial adoption is not partial protection.
But the reading matters more than the doctrine.
Read naively — as a vendor product specification — the Five C’s produce a subtle disaster: they migrate enterprise lock-in from the model layer to the platform layer.
The prison walls move. The enterprise is still inside them. An enterprise that adopts the Five C’s as most Coalition 2 vendors prescribe them — buying Control as a platform’s eval registry, Capability as a platform’s adaptation runtime, Choice as a platform’s orchestration API, Cost as a platform’s routing feature, Compound as a platform’s memory graph — has decoupled from a specific frontier lab and coupled itself to a specific enterprise platform.
Three to five years from now, that enterprise will be structurally married to Microsoft, Palantir, or Databricks, with the same permanence it once had with Oracle, SAP, or IBM.
Read structurally — as vendor-neutral architectural principles — the Five C’s produce something different: real enterprise AI independence, calibrated against the honest constraint that total independence is impossible in an ecosystem this interwoven.
Compute lives on hyperscalers. Frontier models come from a small number of labs. Frameworks come from open communities and vendors. No enterprise can escape all of these. What is achievable is maximum practical independence — distributed dependencies such that no single vendor’s leverage over the enterprise is structural.
This piece dissects each C in full: what it structurally defends against, what the vendor trap for that C looks like, what real ownership requires, how the C connects to the routing layer, and what practical implementation looks like at enterprise scale.
It then walks through the interlock (why the C’s must hold simultaneously), the realistic limits of independence (what enterprises must accept), and the portfolio and implementation gradients that turn the framework into an operating manual.
