Enterprises spent the past two years choosing a model. That was the wrong unit of decision. Models are released, repriced and retired on a cycle measured in months, while the systems built around them are expected to last for years. Companies that treat the model as a foundation will rebuild every time the market moves. Companies that treat it as a replaceable tenant will simply move the better one in.
Prototypes hard-code the model, and production inherits the choice.
A prototype calls one provider's API. Prompts are tuned to that model's habits, tool definitions follow its format and response parsing assumes its output. When the pilot succeeds, the team scales the code instead of redesigning it.
A year later the model sits in every layer: presentation, business logic, data access and testing. Switching would mean touching all of it, so nobody switches, even when a cheaper or stronger option is available. The cost shows up three ways. The company pays premium prices for routine work, misses capability gains that competitors adopt, and loses its negotiating position at renewal.
The model should occupy one layer of eight, and nothing else should depend on which model it is.
In architecture work for a large private equity firm, we separated the platform into eight layers: users and personas, use cases, a per-client presentation layer with human review, channel-independent interfaces, business logic running on Model Context Protocol servers, data and integration, a multi-model layer and infrastructure. The model lives in one of them.
Business rules live in code and in an industry ontology that the model reads but does not own. Financial figures are calculated deterministically and never generated. This separation changes the economics of change: replacing a model becomes a configuration change and a test run rather than a rewrite.
Choose models for tasks, not for the company.
Four design rules keep the model replaceable.
Put a stable contract around every task. Define the inputs, outputs and quality threshold for extraction, classification, drafting and reasoning independently of any provider.
Keep calculations and rules in code. Language models are for language. Numbers, eligibility rules and policy logic run deterministically, so they survive a model change and pass an audit.
Expose tools through open protocols. Model Context Protocol servers let any compliant model use the same governed tools, with permissions enforced at the server rather than in a prompt.
Keep your own evaluations. A test set built from your own tasks is the only fair way to compare a new model with the current one. Without it, every switch is a leap of faith.
Replaceability pays off in cost, quality and leverage.
With these rules in place, organizations can send each task to the model that meets its bar at the lowest cost, adopt new capabilities within weeks of their release and negotiate from a position of choice. They also carry less risk. When a provider changes its terms, degrades a model or goes down, a tested fallback is already in place.
Three questions show how locked in you already are.
If your primary model doubled in price tomorrow, how many weeks would it take to move? Do your business rules live in code or in prompts? Do you have a test set that could prove a new model is better on your own work? If the answers are months, prompts and no, the model has become your foundation, whether or not anyone decided it should.