Every AI application built today is quietly betting that one specific frontier model stays available, stays priced where it is, and stays at least as capable as the day you shipped. Most of the engineers who built the thing never realized they took that bet. It's paid off so far because the frontier vendors have mostly held steady. It won't pay off forever, and unwinding it after the fact costs a lot more than dodging it up front.
I want to argue for one pattern that hedges the bet cheaply. The model agnostic pattern. The shape is simple. Every model call goes through a narrow protocol your application defines, not the protocol the vendor publishes. The vendor's API hides behind an adapter. Your application code has no idea which model it's calling.
The pattern isn't novel. The reason it's worth an article is that the field keeps failing to adopt it, and that failure is starting to compound.
The bet you didn't realize you took
Most AI applications shipped in 2024 and 2025 talk straight to one vendor's API. The base URL is hardcoded. The model name is hardcoded. The request shape is hardcoded against that vendor's schema. The response parsing assumes that vendor's exact output format and nothing else.
This holds up fine as long as the vendor stays in business, keeps the API stable, keeps the pricing predictable, and keeps the model at least as capable as it was on launch day. None of those are guaranteed. They've mostly held for two years, which is luck, not a structural property of anything.
When one of them breaks, the application that leaned on it gets rewritten. Not adjusted. Rewritten. The vendor specific code is scattered across prompt construction, response parsing, retry logic, error handling, and observability, and every one of those has to be reworked to point somewhere else. The cost is real. So is the risk, because every rework breeds new bugs.
Applications built on a model agnostic pattern don't eat that cost. They eat an adapter rewrite, a much smaller surface, and the application logic never moves.
What the pattern looks like
The pattern has four components.
Component one. A narrow protocol the application defines. You spell out the operations you actually need from a model. Most applications need three. Complete a prompt within a max token budget, embed a list of strings, and maybe stream tokens. That's the whole list for a lot of systems. A protocol that captures those is small. The protocol some libraries publish, with fifty methods covering every conceivable model capability, is the wrong abstraction.
Component two. Adapters that implement the protocol against specific vendor APIs. One adapter per vendor. Each one owns the vendor specific request construction, the response parsing, the retry logic, and the error mapping. The adapter is the only place in the codebase that even knows the vendor exists.
Component three. A registry that resolves a model role to an adapter. Application code calls the registry by role, not by vendor. "Get me the verifier model." "Get me the embedding model." The registry hands back an adapter, the application calls the protocol on it, and the application code never learns which vendor answered.
Component four. Configuration that maps roles to vendors at runtime. The mapping lives in configuration, not in code. You can deploy against OpenAI in one environment, Anthropic in another, and a self hosted model in a third, with no code change at all. The mapping is auditable, version controlled, and changeable without a rebuild.
Those four together are the pattern. Nothing exotic. The total investment runs about a week for a small application and two to three weeks for a bigger one. That's a lot less than a single vendor rewrite.
The retrofit cost
If your application already targets one vendor, retrofitting the pattern costs more than building it in would have. How much more depends on how concentrated the vendor specific code is. When the model calls are isolated, a handful of well defined functions own the vendor interaction, you can retrofit in a few days. When that code is smeared across many modules, you're looking at a real refactor.
The signal that it's time to retrofit anyway, even at cost, shows up in one of a few ways.
The vendor changes pricing in a way that materially moves your economics. Now you either swallow the cost or move, and the retrofit is the cheapest road to having a choice at all.
The vendor deprecates the model you depend on. The replacement has different capabilities, different prompt sensitivities, and different output shapes. If the application is going to work against the replacement, the retrofit is mandatory.
A customer demands the option of a different vendor. Some buyers, especially in regulated industries or under data sovereignty rules, simply won't run their data through a particular vendor's API. Serve that customer and the retrofit is mandatory.
Each of these is a forced retrofit. The cost is real, and it's bigger than the proactive version, because a forced retrofit lands on a deadline while the proactive one doesn't.
The long term lever
There's a strategic case here that runs past hedging. Vendors compete on capability and price. An application that can switch vendors at deployment time pockets the benefit of that competition. A locked-in application watches it go by.
In practice the well architected application picks the best vendor per role rather than the best vendor overall. The verifier role might run a small fast model from one vendor. The critic role might run a larger reasoning model from another. The embedding role might run a third vendor's specialized embedding model. You get each vendor's strengths and skip each vendor's weak spots.
That's a real capability edge, and it stays invisible until the architecture can actually exploit it.
What this implies for builders
A few implications matter for teams shipping production AI in 2026.
One. Define the protocol before the first vendor integration. The temptation is to build straight against the vendor and abstract later. Don't. The abstraction is harder to retrofit than to build. Designing the protocol takes a day. The retrofit takes weeks.
Two. Resist exposing vendor specific features through the protocol. Every vendor has features the others lack. Function calling here, JSON mode there, structured output somewhere else. The urge is to surface all of it through the protocol so the application can use it. Don't do that either. An application that reaches vendor specific features through the protocol is locked in even though the protocol technically exists. The protocol should expose only what every vendor supports. Vendor specific features can live inside the adapter when you genuinely need them, but they shouldn't bleed through.
Three. Test the swap on a schedule. A model agnostic application that hasn't run against a second vendor in three months isn't agnostic anymore, it just thinks it is. The pattern only holds if you exercise the swap. Put a run against a secondary vendor in CI at least monthly. The cost is small and the confidence is large.
A closing observation
The model agnostic pattern isn't complicated engineering. It's a small investment now that buys meaningful optionality later. The applications that adopt it pay a little premium today and collect a real benefit the day one of those vendor assumptions changes.
The applications that skip it are betting that none of the assumptions ever change. That's a bet the field has lost before. Vendors change pricing, retire models, rewrite terms of service, and shift capabilities on cadences nobody's product roadmap was built to absorb.
The right architecture for production AI in 2026 doesn't care which vendor sits in the request path. Teams that internalize that will be running cleanly in 2028. The ones that don't will be drafting internal postmortems about why the rebuild took longer than anyone projected.