How to thrive in a multi-model world

Enterprise AI value lives outside of the model, in the context, tools, policies, and knowledge around it. It’s imperative that you own it.

It stops making sense when the CFO opens the invoice. The successor discipline is tokenomics: treating tokens as a governed unit of production cost that is attributed and Enterprises rent the model and build the system. But right now, most enterprises are building that system inside someone else’s walls, with little to no control.

This paper makes four arguments:

The dangers of walled gardens

The frontier labs and hyperscalers are not running a scheme. They are doing what well-run companies do: shipping coherent, vertically integrated products. OpenAI and Anthropic have built genuinely good agent stacks. The hyperscalers have wrapped those stacks in managed platforms that are easy to adopt and demo. That quality makes the walls hard to see.

Savvy leaders are watching where artifacts accumulate. For example:

• Agent definitions get written in one provider’s format
• Tools and skills are packaged in a way that only one runtime loads
• Memory and conversation cannot be exported with fidelity
• Evaluation suites and traces live in one vendor’s console
• Guardrails are expressed in a policy language with a single implementation
• Orchestration features are available on a first-party endpoint and nowhere else

No single item on the list above is a locked door. But if one or more of the artifacts sounds familiar, you face a growing swell of switching costs.

Independent analysts have started naming the mechanism. Kai Waehner, who advises Global 2000 enterprises on AI architecture, observes that when agents run on a vendor’s proprietary orchestration layer, “lock-in compounds at every layer of the stack.” Model choice, workflow automation, data, governance, and staff expertise become entangled with a single vendor, and each dependency multiplies the others.

Enterprises feel the weight before they can name it. In a 2026 AvePoint analysis of AI vendor dependency, 47 percent of enterprise executives said losing their primary AI vendor entirely would disrupt a key business function. When Builder.ai, a Microsoft-backed platform once valued at 1.3 billion dollars, collapsed in 2025, customers found themselves unable to access systems and data they had built their operations around.

The pattern is familiar to anyone who lived through the early cloud era, when enterprise workloads accumulated behind proprietary orchestration APIs, Kubernetes emerged to move the substrate into the commons. The same accumulation is happening one layer up. The difference is what gets trapped this time: not infrastructure configuration, but the enterprise’s own operational knowledge.

Trends reshaping AI initiatives

Three changes in the AI market make this lock-in more expensive than it looked a year ago.

All three shifts point in the same direction: the value of flexibility at the model layer is rising, and the walled-garden architecture is precisely what prevents enterprises from capturing it.

What is at stake

Gartner predicts that over 40 percent of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls. Anushree Verma, Senior Director Analyst at Gartner, describes most current projects as “driven by hype” and “often misapplied.”

Why do agent projects fail? Model capability is not on Gartner’s list. The top factors are (1) cost, (2) value measurement, and (3) risk control. All of these are properties of the system around the model. Enterprises are not failing because the models cannot do the work; they are failing because the system that would make the work governable, measurable, and affordable was either never built or was built inside a stack that hides its costs and constraints.

Define your agent stack

The word “agent” hides the parts that matter. The system an enterprise builds around a model includes, at minimum:

• The harness. The runtime that plans, invokes tools, retries and repairs failures, and hands results to the next step. This is where most agent engineering effort actually goes, and where a vendor’s proprietary formats bind deepest.
• Tools. Standards-based interfaces to enterprise data and actions, increasingly via MCP servers. A tool inventory encodes years of decisions about which systems agents may touch and how.
• Skills. Instructions and packaged behaviors an agent can load: how to file a ticket, how to structure a compliance memo, and how your organization defines done.
• Context. Documents, playbooks, conversation histories, and the pipelines that assemble them. Context engineering is where domain knowledge becomes machine-usable.
• Memory and state. What agents learn across sessions and carry through a task in flight. A memory store that exports only as a transcript dump is not owned; it is hostage.
• Evals. The test suites and results that define what “correct” means for your business. Evals are how buyers exercise choice (and ensures vendors don’t grade their own homework).
• Policies and audit. Who may call what, under which constraints, with records a security team can inspect. Regulations such as the EU AI Act require exactly the kind of inspection that black-box stacks resist.

Claims adjudication, clinical documentation, fraud investigation, chip verification: the domain knowledge for these lives in enterprises, not in labs. Every one of the above listed components encodes that knowledge, which means every one of them is an asset, and every one of them is currently at risk of being expressed in a format only one vendor can run.

The seams are starting to open. Finish the job.

The industry has already proven that neutral seams work at this layer. The Model Context Protocol, released as an open standard in November 2024, was rapidly adopted by OpenAI, Google, Microsoft and more, and its SDKs now see roughly 100 million monthly downloads. In December 2025, the protocol was donated to the Agentic AI Foundation under the Linux Foundation, placing tool connectivity under vendor-neutral, community governance. The public server ecosystem has passed 10,000 active servers.

MCP demonstrates the pattern: publish the seam, govern it neutrally, and an entire market forms around it. The protocol’s own maintainers report that enterprises deploying it now run into a predictable set of production needs, including audit trails, SSO-integrated authentication, and configuration portability. Those needs mark the frontier of what must open next.

Because one open seam is not an open system. Tool connectivity is standardizing. Agent and skill definitions, memory and state export, evaluation formats, and policy languages remain, for the most part, proprietary to each stack. An enterprise can move its tools today and still lose its agents, its accumulated context, its evaluation history, and its policy posture in a migration. The commons needs to extend across every component listed above, with conformance that is tested rather than asserted.

The case for an open agent platform

An open agent platform is the architecture that follows from these facts: open-source components, specified interfaces at the seams, and every artifact in the system stored in a form that any runtime can execute. The argument for it comes down to three kinds of control.

The argument for vertically-integrated stacks

Vertical integration is producing excellent systems right now. Offerings from the frontier labs and hyperscalers have increasingly improved in performance. Tight coupling between a model and its harness lets a lab co-design them and ship capability faster. Premature standardization is a real failure mode, as it can calcify layers that should keep moving.

The answer is sequencing. Standardize where the shape of the problem is understood, and let the rest race. Tool invocation is already standardized and thriving. Agent definitions, state export, evaluation formats, and policy expression are understood well enough to specify now. Nobody is proposing to freeze reasoning architectures or force labs to open their weights. The ask is narrower: the joints between the pieces should be public, specified, and testable, and the first-party path should be one path among several rather than the only executable one.

In reality, some will go all in on one particular model, vendor, or system and be successful. It’s up to your organizational values, relationships, and risk appetite to decide if all in makes sense. Your team has to commit to those risks.

The five-part test to protect against lock-in

The practical version of this argument fits in a procurement requirement. Before committing to any agent platform, ask five questions and require demonstrations, not assurances:

Then actually run the export, before signature, while you still have leverage. If a platform cannot pass these tests, you are moving in as a tenant, and the rent will be set after you have unpacked.

Enterprises still hold the advantage, because the substrate of the agent era is being poured right now and no vendor’s position is locked. The system around the model is where your value will live for the next decade. Own it, keep it portable, and make every vendor compete for the right to run it.