The Single-Provider Trap Is Coming to Enterprise AI

The most expensive AI decision many companies will make in the next few years will feel like the safest one. It will look just like many previous cloud decisions did: pick a vendor, move fast, and assume portability can be cleaned up later. In AI, that means choosing a single frontier model provider, adopting its hosted agent stack, and assuming any architectural consequences can be unwound down the road. That works for a pilot because everything is convenient at the same time - one SDK, one hosted memory layer, one eval surface, one commercial relationship, one vendor telling a coherent story. Then the workload shifts from chat to agents, the spend curve stops being linear, the best model for one class of work is no longer the best model for another, and the framework that made it easy to get started begins to make leaving feel less like a migration and more like open-heart surgery.

That is why I increasingly think LLM agnosticism is becoming a strategic requirement for enterprise AI, not a technical preference or a purity argument. The recent Information Report on Anthropic’s changes to enterprise pricing for heavy business usage is significant because it shows how quickly the economics can shift once workloads become serious. Providers will price for their own compute constraints, capacity limits, and margin objectives, and they will work hard to pull customers deeper into their own hosted agent ecosystems. That is entirely rational from their side. It is simply not a stable basis on which to build the rest of your company’s operating mode in a market this volatile, this politically exposed, and this fast-moving.

The durable asset is not the model endpoint. It is the agentic system that governs how models interact with your data, memory, context, tools, and policy. If that layer belongs to you, providers compete for your workloads, the best models can be chosen task by task, and switching remains an engineering exercise rather than a strategic crisis. If that layer belongs to them, your economics, privacy posture, and exit costs are all downstream of somebody else’s platform strategy. Avoiding that trap requires more than a gateway. It will require owning the runtime.

The Anthropic pricing change is a useful signal because it exposes a deeper truth about agentic AI economics. Once usage shifts from seat-based productivity into long-running coding agents, scheduled work, tool use, retries, and autonomous workflows, pricing stops being a clean per-user abstraction and starts to reflect raw consumption. The Information piece suggests that some heavy Claude Enterprise users could see costs double or even triple under the new structure, and it notes similar usage-sensitive moves elsewhere in enterprise AI. This is probably not an outlier, but what happens when providers discover where the expensive workloads are.

And price is only one axis of dependency. The frontier model market is moving too quickly, its economics remain too unsettled, and its policy environment is too uncertain for any serious company to commit its architecture to one provider’s roadmap. You do not know which firms will still be structurally advantaged in three years, whose gross margins will hold, which models will end up constrained by regional regulation or procurement rules, or where governments will decide strategic control points need to sit. Frontier models are already close enough to strategic infrastructure that export controls, access restrictions, or safety interventions can no longer be treated as remote possibilities.

That is too much uncertainty to absorb passively. The practical response is to make model choice reversible.

This matters because different model families genuinely excel at different kinds of work, and the best answer is rarely “pick one and standardize everything around it.”

In many enterprise teams, the picture has already shifted noticeably over the last three months. For coding workflows in particular, many teams have begun moving from Claude toward Codex, not because Claude has stopped being useful, but because OpenAI is often better at following precise instructions, operating inside tighter agentic control loops, and using tools in a more disciplined way over longer execution chains. Claude still has a distinct strength of its own: it is often better at finding a user’s underlying intent inside messy, ambiguous conversation, which matters in workflows where the hardest problem is understanding what was actually meant before any action is taken.

Neither choice should dictate the architecture of the whole company.

There is another advantage to model plurality that is still underused: one model can check another’s work. A model that proposes an action is often a poor judge of its own blind spots, especially if the same family is also being asked to validate the output, grade the result, and decide whether to continue. Once you let a second model from a different provider review the work, or better still attack it, you reduce correlated failure. One model writes the code change, another looks for the edge case; one proposes a customer action, another searches for the compliance or policy problem; one drafts the plan, another tries to break it. What matters is not merely a second opinion, but a second failure distribution.

That diversity also gives you a more rational cost structure. Not every step justifies the most expensive model, and not every task should be solved with the model you happened to start with six months earlier. The ability to route by task, validate across families, and change those choices without a replatform is what low switching cost actually looks like in practice.

The strongest form of lock-in is not the API call. It is where your memories, context, ontology, and workflow semantics end up living.

Hosted agent frameworks are attractive because they compress months of work into days. They ship with managed memory, built-in tracing, default planners, integrated evals, native tools, and smooth developer ergonomics. That convenience is real, but so is the functional limit. Most are optimized for their own abstractions, their own storage assumptions, their own tool semantics, and their own view of governance. They tend to treat context as a provider-native payload rather than a governed architectural layer, which is exactly why they feel so productive at the start and so constraining later.

This is where sovereignty stops sounding abstract and becomes operational. Data sovereignty in this sense does not just mean “keep the files private.” It means the enterprise owns its memories, context layers, business ontology, approved tools, versioned queries, access rules, and audit trail. It means a model can invoke a reviewed and approved query by name rather than inventing live query logic in production. It means credentials remain at the gateway or data-access layer rather than inside the agent loop. It means the map of enterprise meaning, how customers, products, policies, mandates, exceptions, and actions are actually defined, stays on your side of the boundary.

That is the layer that compounds with use, and it is the layer you do not want to hand away.

We have seen this pattern before in the cloud. Single-provider choices did not usually hurt in year one; they became painful in year three, when data gravity, egress, proprietary services, and rewrite costs converted earlier speed into later dependency. AI providers are now trying, quite sensibly, to move up the same stack. They do not want to provide only inference; they want the hosted agent framework, the memory layer, the eval system, the tracing surface, and the developer workflow that makes your application harder to move. The easiest architecture to start with is becoming, again, the hardest one to leave.

There is, however, one important caveat that gets missed in simplistic “multi-model” discussions: an LLM-agnostic system is not just a gateway.

The transport layer is the easy part. The hard part is behavior. Different model families want different prompt structures, tool descriptions, context packing strategies, result validators, retry policies, stop conditions, and cache behavior. Real agnosticism does not mean pretending Claude, OpenAI, and a local open model are interchangeable. It means keeping the invariant layers, your data fabric, memory, ontology, policy controls, audit, and tool execution, on your side, while versioning prompt packs and task variants by model family and even by model version so each one is optimized for the work it is doing.

If you want low switching cost without dropping into lowest-common-denominator behavior, you need a canonical internal representation of prompts and tasks, with provider-specific translation at invocation time, and you need different prompt versions retained for different families because the same task often performs differently across them. In other words, low switching cost is not achieved by denying model differences; it is achieved by containing them.

This is one of the reasons we designed our ContextOne architecture in the way we did. The runtime is LLM-agnostic, but it does not assume identical behavior across model families. It preserves the enterprise’s control over memory, ontology, audit, and policy while allowing prompts and tasks to be optimized for specific providers and versions. That is the appropriate kind of complexity, because it buys flexibility where it matters and specialization where it pays.

Once you own orchestration, smaller local open models stop being ideological and start being practical.

They can run in side-chains alongside the main agentic loop, handling tasks that are narrow, repetitive, privacy-sensitive, or simply not worth frontier-model pricing. A local model can classify inbound documents, normalize entity names across messy systems, rerank retrieved passages, or perform first-pass policy and code checks before the frontier model is called.

These side chains can run in parallel with the main loop, which means the gain is not only lower cost but also lower latency and reduced exposure. The frontier model spends its budget on reasoning rather than housekeeping, while the most sensitive or repetitive steps remain inside the enterprise boundary. For regulated businesses, that hybrid pattern is usually much better than the false choice between “everything hosted” and “everything local.”

The strategic question is not which model vendor looks strongest this quarter. It is whether the company owns the runtime that governs data, memory, ontology, tools, and policy, because that layer determines pricing leverage, privacy posture, resilience, and exit cost. It is the layer that compounds with use. A company that owns it can let model vendors compete inside its system; a company that does not is effectively underwriting the platform risk of the vendor it chose first.

For most serious enterprises, the disadvantages of running their own agentic system in-house are front-loaded and manageable, while the benefits compound over time. You take on more architecture, more governance work, and more operational discipline up front; in return, you get lower structural risk, better cost control, stronger privacy, clearer ownership, reduced lock-in, and the freedom to use the best model for each task rather than the model you happened to standardize on early.

None of this means provider ecosystems are useless. They will remain valuable learning surfaces, and for many teams they will still be the fastest way to get started. But as soon as AI touches core workflows, proprietary data, and real budgets, convenience stops being the right optimization target. Risk, cost, lock-in, ownership, and privacy move to the front of the queue.

That is why the more durable pattern is to keep the context and control architecture on the enterprise side of the boundary, let frontier and local models work together inside it, and make model choice reversible. We build around that principle: LLM-agnostic at the runtime layer, optimized by model family where it matters, and structured so the enterprise keeps the memories, ontology, and controls that actually become more valuable with use.

The companies that benefit most from this cycle will not be the ones that guessed the eventual winning model provider. They will be the ones that refused to bet the rest of their architecture on that guess.