Switching models should cost one line
Every few months a model ships that beats the last one. If your system has a favorite, you turned a one-quarter advantage into a dependency that lasts years.
El YuntComunicaciones
Every few weeks a lab launches a new model and announces it is the best in the world. For a quarter or so, it is right about part of your work. Then someone else launches theirs and the crown changes heads. That leaderboard works like a revolving door.
Most companies react as they would to any technology purchase: compare, pick a winner and standardize. With AI models that reflex is a strategic mistake. The problem is not ending up with the wrong model. The problem is building a system that has a favorite. When your processes, your instructions and your data are tied to one provider, every advance from the others ends up costing a project. You turned a three-month advantage into a dependency that lasts years, and you did it on purpose.
The market already understands this. According to Menlo Ventures, 37% of companies already run five or more models in production, and none of them holds the lead across every task.
Tying yourself to one model freezes a snapshot
You are putting a snapshot of this quarter into a system that has to run for years, and the snapshot expires in months. No model is the best at everything. One leads in complex reasoning, another in reading documents, another on cost, another on speed, another in running inside your own servers. If you standardize on one, you swallow its weaknesses everywhere, even where another would do better.
And the dependency runs deeper than a connection to an API. It lives in the instructions someone spent months tuning to that model's quirks, in the way the company's information was indexed for that provider, and in the tools built to its format. Switching later is already a migration, and that is why almost nobody switches.
Going with one of the big ones won't protect you either
According to the same Menlo Ventures study, three companies, Anthropic, OpenAI and Google, account for about 88% of enterprise language model usage. That figure makes people believe any of the three is a safe bet. It is the wrong conclusion. The heaviest users of AI refuse to choose. Walmart, according to industry press, built systems that split each request among GPT, Claude and Gemini depending on cost, speed and the type of task.
They treat the model as what it is: an input that competes and gets replaced. Safety comes from being able to move, not from the size of the brand you hide behind.
Married to a model or agnostic, point by point:
Best model: wait on one provider's calendar, or use the new one the week it ships.
Cost: one price for everything, or each task on the cheapest model that does it well.
Continuity: an outage or a price hike hits everything, or the work moves to another model.
Privacy: whatever the provider allows, or sensitive work on a local model.
Upgrading: a migration project, or a configuration change.
Your advantage: in a model you don't control, or in your process, your rules and your record.
Your advantage lies in what surrounds the model
The model is becoming an input, like electricity. Nobody builds their strategy around which company sells them power. What lasts is what you put around the model: which stage of the work goes to which engine, what each action costs, which controls make sure the result is correct, who reviews and signs, and who answers when something fails. In another column we called it the harness. A model delivers an answer that sounds right. An operation delivers a correct result every day, and the model is only one of its parts.
The money makes it clear. Using the biggest model for every task is the most expensive way to work with AI, and rarely the most accurate. Sending simple, repetitive work to small or local models lowers the bill and leaves frontier models for what truly demands reasoning. You can't do that if your system is married to a single cloud model.
In our digital collaborators that math shows up in the glassbox: every action is written down with its reason and its cost. With that record in view, the question stops being which model to standardize on and becomes which model each stage of the work deserves.
Build so that switching models is a formality
It takes four things. A layer that picks the model by task, looking at accuracy, cost, speed and privacy. The model behind your own interface, so a new release is a configuration change and not a rebuild. Small and local models in the mix, for work that has to be private or cheap. And the same controls for any model, so that swapping the engine never weakens the record, the approvals or the review.
That is how we work. The role manual, the rules, the data and the record of what the collaborator did live outside the model, in a folder that belongs to the client. When a new model comes out, we test it on real cases from the role before trusting it with the work. If it performs better, one line changes and everything else stays the same. And if the client wants to leave, they take their manual and their record with them.
The useful question for your team is not which model to standardize on but this one: when the next model comes out and beats today's best, how long would it take us to use it and what would we have to rewrite. If the honest answer is "months" and "a lot", you don't have an AI strategy. You have a bet on one company's product plan.
Built this way, the engine changes underneath and the process, the controls and the results stay yours. You don't depend on an AI provider. You depend on your collaborator.
Sources
Menlo Ventures, 2025: The State of Generative AI in the Enterprise (37% of enterprises running five or more models in production; Anthropic, OpenAI and Google with about 88% of enterprise usage).
Walmart's routing across GPT, Claude and Gemini, as reported in industry press, 2025-2026.

