In 2009, BlackBerry Enterprise Server was the backbone of corporate mobility. Fortune 500 IT departments had built their security policies, compliance frameworks, and employee workflows around it. Then the iPhone happened. BlackBerry’s share went from 20% to under 1%. But here is the part most people forget: corporations mostly got through it. The transition was expensive and slow, but the market did most of the work. Apple and the carrier ecosystem made switching possible. MDM vendors bridged the gap. The old platform died on a timeline that gave companies room to adapt. It was painful, but it was survivable.
The AI model layer is replaying that cycle at ten times the speed, and this time, the market will not rescue you.
Six OpenAI models have been deprecated or retired in the past twelve months. GPT-4.5 lasted fourteen months from launch to deprecation. Companies are building workflows, fine-tuning prompts, and training employees on models that their providers may retire before the project reaches full production. The switching costs are not theoretical. They are accumulating right now, in every saved prompt, every fine-tuned workflow, every team trained on a single vendor’s interface. And unlike the BlackBerry transition, there is no carrier ecosystem building bridges for you. There is no five-year runway. The model you committed to last quarter may already be on a deprecation timeline you have not seen yet.
We advise companies across sectors on AI strategy, and in our assessment, this is the highest-impact architectural decision that is getting the least executive attention. The model selection conversation dominates boardrooms. The switchability conversation barely registers. That asymmetry is where the real risk lives. The architecture that enables switchability is inexpensive to build today. It will be extraordinarily expensive to retrofit once workflows, prompts, and team habits have calcified around a single provider.
The companies designing for that question, designing for switchability, are making three architectural decisions differently from everyone else.
The Interface
JPMorgan rolled out an internal AI assistant called LLM Suite to 250,000 employees in 2025, and half of them now use it daily. The system runs on models from OpenAI and Anthropic, but what matters architecturally is that the interface belongs to JPMorgan. Employees interact with JPMorgan’s chatbot, not with Claude.ai or ChatGPT Enterprise. Their prompt habits, their workflows, and their daily usage patterns all accumulate inside a system that JPMorgan controls.
That design choice has a strategic consequence. Because the interface is decoupled from the model, JPMorgan has the architectural freedom to add, replace, or remove model providers without disrupting the employee experience. Whether they have needed to exercise that freedom yet is beside the point. The point is that they can, and that the 250,000 employees who depend on the system would not need to change how they work if a model underneath it were deprecated tomorrow.
The opposite of that design is what we see in many of the companies we advise. They adopt a vendor’s native console as their primary AI interface, and as usage grows, the switching costs compound silently. Every saved prompt, every custom workflow, every team’s learned behavior becomes a reason to stay, even when better or cheaper alternatives exist. The interface that felt like a simple procurement choice in month one becomes an architectural constraint by month twelve. Owning the interface is the first decision, and it shapes everything that follows, because it determines whether you retain the freedom to make the second.
The Engine
Once you own the interface, the question becomes what sits behind it. And here the most seductive trap in enterprise AI presents itself: committing to a single model provider for the depth of the relationship. Better pricing, earlier access to features, a named account team, a direct line to the product roadmap. For the first year these benefits feel like the right trade. The problem is that every workflow, every fine-tuned prompt, and every integration you build over that year gets coupled to a platform whose roadmap you do not control. An architecture locked to GPT-4.5 in March 2025 was locked to a dead model by July.
The market has shifted in a way that makes single-provider commitment harder to justify. GPT-5.5, Claude Opus 4.7, and Gemini 3.1 Pro now trade leadership across major benchmarks, with no single model dominant across all enterprise workloads. That convergence means the foundation model is, for the first time, a genuinely replaceable component. Not because the models are identical, they are not, but because the differences between them are task-specific and shifting, which means the right model for a given workload today may not be the right model six months from now.
Goldman Sachs designed their internal AI platform around this assumption. The GS AI Platform hosts models from OpenAI, Google, Meta, and Anthropic behind a single gateway, and is architected to route different types of requests to different models based on task fit. The design intent, as described by Goldman’s technology leadership, is that adding or removing a model is a configuration change rather than a rebuilding project. That architectural choice gives Goldman the option to respond to model deprecations, pricing changes, or capability shifts without reworking the applications that depend on the platform.
You do not need Goldman’s engineering team to design for this. The decision is not about the size of your infrastructure. It is about whether you make the commitment to a single provider before or after you have built the ability to leave. That question leads directly to the third decision, which determines whether the first two actually hold together.
The Framework
Between the interface your employees use and the model that answers their questions sits an orchestration layer. It decides which model handles each request, what context from your data to attach, what guardrails to apply, and how to evaluate whether the response meets your standards. This is the LLMOps layer, sometimes called the AgentOps layer as autonomous agents become more common, and it is the decision most companies underbuild. When this layer is substantial, it accumulates institutional knowledge, prompt patterns, evaluation benchmarks, and domain-specific context that make your AI stack more valuable over time regardless of which model sits underneath. When it is thin, it is just a pass-through to a vendor’s API, and everything your organization learns about using AI effectively lives in the vendor’s system instead of yours.
Intuit offers the clearest public example of what a substantial orchestration layer looks like. Their system, called GenOS, is designed as a four-layer operating system that routes queries to whichever model fits the task, switching dynamically between commercial, proprietary, and open-source LLMs. Ashok Srivastava, Intuit’s Chief AI Officer, has described the design philosophy explicitly: the system is built so that the model is never the bottleneck. GenOS powers Intuit Assist across TurboTax, QuickBooks, Credit Karma, and Mailchimp, serving over 100 million customers. The scale is significant, but the principle is what matters. Intuit designed the system so that the value accumulates in the orchestration layer, not in any single model underneath it.
That design philosophy is the heart of the third decision. A company that builds a real orchestration layer, one that captures domain-specific evaluation criteria, manages prompt libraries tuned to its own use cases, and maintains the flexibility to route across providers, is building an asset that compounds over time and survives model churn. A company that treats LLMOps as a thin wrapper around a single vendor’s API is building a dependency that gets more expensive to exit with every passing quarter. This is the layer the BES-dependent companies never had. It is the layer that makes the platform underneath it survivable.
The Through-Line
The interface. The engine. The framework. Three decisions that together determine whether your AI stack grows more resilient with every model cycle or more fragile. The companies designing for switchability across all three layers are building AI capabilities that can absorb the churn the model market is producing. The companies that are not are accumulating switching costs that will eventually come due, at a speed and scale that will make the BES unwinding look manageable by comparison. The BlackBerry transition gave companies years. The AI model market is not offering that courtesy.
The difference was never about picking the right model. It was about building a stack where picking the wrong one could not hurt you.
Switchability is not a hedge. It is the moat.
These three layers are how we organized our 2026 Corporate Buyer’s Guide to Enterprise Intelligence Applications: enterprise chatbots, foundation models, and LLMOps/AgentOps platforms. The decisions are yours. The vendor landscape is what we cover. For more information, visit gaiinsights.com.
By GAI Insights Team
