There is a specific type of enterprise technology regret that surfaces not at the point of adoption but three to five years later, when the strategic landscape has shifted and the cost of changing course has compounded to the point where it shapes every subsequent decision.
It is the regret of lock-in that was not recognised as lock-in at the time it was being accepted.
The Oracle database decision that made sense in 2005 was not obviously a lock-in decision at the time. It was a capability decision - the best database for the enterprise's needs, with a vendor that had the deepest support and the broadest ecosystem. The lock-in dimension only became visible when migration costs made it effectively permanent.
The same story played out with SAP implementations, with cloud provider lock-in as infrastructure moved to the cloud, and with SaaS platform consolidation as enterprise software portfolios rationalised.
The enterprise AI OS decision - specifically, the decision about which vendor's context and control layer the enterprise AI infrastructure runs on - is the same type of decision. It does not look like a lock-in decision today. It looks like a capability decision, a convenience decision, a build-on-the-platform-you-already-have decision.
The lock-in dimension will become visible in three to five years, when swapping the model requires rebuilding the semantic layer, when the audit trail is vendor-proprietary and not portable, and when the governance policies that enforce what agents can do are encoded in a format only one vendor's platform can interpret.
Where the lock-in actually sits in the AI OS stack
The model layer is not where AI OS lock-in accumulates. Foundation models are already the most substitutable component in the enterprise AI stack - API interfaces are standardising, switching costs at the model layer are relatively low, and the competitive pressure from multiple capable vendors keeps the market from consolidating around a single provider.
The lock-in accumulates in the two layers immediately above the model: the context layer and the control plane.
Context layer lock-in occurs when the knowledge graph, semantic definitions, and ontological structure that enterprise AI agents reason from are built inside a specific vendor's platform and stored in a proprietary format.
The value of the context layer compounds over time - more entities added to the knowledge graph, more relationships defined, more semantic ambiguities resolved, more business rules encoded. Every increment of that value, if it is built inside Google's Knowledge Graph, Databricks' Genie Ontology, or Microsoft's semantic layer, is an increment of value that is increasingly expensive to migrate away from.
Control plane lock-in occurs when the governance policies, audit trail infrastructure, and permission frameworks that govern what enterprise AI agents are allowed to do are built inside a vendor's proprietary governance system.
When the EU AI Act requires the enterprise to produce an audit log for an AI decision made eighteen months ago, and that audit log is stored in Microsoft Purview's proprietary format, accessible only through Microsoft's tooling, with retention policies set by Microsoft's platform defaults - the enterprise's ability to demonstrate compliance is dependent on its vendor relationship remaining intact and cooperative.
"Build context once, every MCP-capable model reads the same unit, and swapping models doesn't touch the context. That is the model-agnostic architecture. The question is whether your context layer was designed for it - or whether it was built inside a platform that makes the swap structurally impossible."
What model-agnostic actually requires in practice
Model-agnosticism at the context and control layer is not a philosophical preference. It is an architectural choice that requires specific design decisions at the point of building - and becomes significantly harder to achieve retroactively once the context and control infrastructure has been built inside a vendor's platform.
The practical requirements for a model-agnostic context and control layer:
Open protocol support. The context layer must serve context through open protocols - MCP (Model Context Protocol) and A2A (Agent-to-Agent) - so that any model or agent framework can consume context without a vendor-specific integration.
Context built once in an open format is readable by GPT, Claude, Gemini, and any future model. Context built inside one vendor's proprietary format requires translation or reconstruction to serve a different model.
Portable knowledge representation. The knowledge graph, semantic definitions, and ontological structures that encode enterprise knowledge need to exist in a format that is exportable, version-controlled, and not dependent on any single vendor's runtime to be interpreted. RDF, OWL, and Apache Iceberg-based storage are examples of formats that achieve this. Vendor-proprietary knowledge formats are not.
Vendor-neutral audit infrastructure. The tamper-evident audit trail that governance and compliance require needs to be stored in a format and location that the enterprise controls - not in a vendor's infrastructure where access, retention, and format are governed by the vendor's platform terms.
Separation of governance policy from enforcement infrastructure. The policies that define what AI agents are allowed to do - the access controls, the permission scopes, the escalation rules - should be defined and owned by the enterprise, in an open policy language like OPA (Open Policy Agent).
The enforcement infrastructure can be vendor-provided, but the policies themselves should be portable - expressible in any compliant enforcement layer rather than encoded in a single vendor's proprietary governance format.
The practical architecture that preserves independence
The enterprise that wants to preserve genuine independence in its AI OS makes three structural choices that differentiate its architecture from one that is accumulating vendor lock-in by default.
First, it separates the context layer from the model layer architecturally - building context in MCP-compatible, open-protocol formats so that context built today is consumable by whatever model the enterprise uses in two years, without reconstruction.
Second, it builds the knowledge graph and semantic definitions in portable formats and in infrastructure the enterprise controls - not inside a vendor's proprietary knowledge graph that requires that vendor's runtime to serve.
Third, it ensures the audit trail and governance policies are enterprise-owned assets - stored in locations and formats the enterprise controls independently of any vendor relationship, accessible to compliance teams through standard tooling rather than through vendor-specific interfaces.
None of this requires avoiding major vendors. Microsoft, Google, and Databricks all provide genuine value and will remain part of most enterprise AI stacks. What it requires is choosing deliberately which layers of the AI OS are built inside vendor platforms - accepting the convenience and accepting the constraints - versus which layers are built in portable, open-standard formats that the enterprise can migrate, extend, and govern independently of its current vendor relationships.
The model decision is reversible. The context and control layer decision is not - or at least, it becomes progressively less reversible with every month of context that compounds inside a proprietary format. The enterprises making this architecture decision today are the ones who will or will not have that reversibility available in 2028, when the AI OS landscape looks different from what any vendor is projecting now.
Build the AI OS you want to own in five years. Because by the time it becomes clear you should have, it will already be the one you are stuck with.
