When the model underneath improves, only that layer should swap, and the log should show whether it actually helped.
No, not if your setup keeps its context and configuration separate from the model underneath. When a new model ships, only that layer swaps. A rebuild happens when prompts, parsers, and workflows are wired straight to one model, so the better model breaks the setup tuned to the old one.
The rebuild is expensive because of proportion. As one firm puts it, companies locked to a single model pay twice, once to build and again to migrate, because the model is only 10 to 20 percent of the system and the workflow around it is the other 80. Wire the 80 to the 20, and every change to the small part rebuilds the large one.
Companies locked to a single AI model pay twice, once to build and again to migrate, because the model is only 10 to 20 percent of the system and the workflow around it is the other 80.
Tech10, 2026
If the setup is wired to the old model, a better one can break it overnight. When Google announced the deprecation of several Gemini models, prompts that had been tuned for months began producing different outputs, and the teams that had built directly on the model owned every fix. Extraction that read a document correctly one day scrambled the fields the next. Nothing failed on your side. The ground under the setup moved.
The cost of that move is not a quick re-paste. In one account, a model update turned three months of extraction-prompt calibration at a financial-services firm into two weeks of rework. Read that as direction, not a benchmark, but the direction is the point: making your setup work on the next model is real, budgeted work that recurs every time the model changes.
You can, when the model sits behind an abstraction the rest of your setup talks to instead of the model directly. The named pattern is a gateway. A gateway presents one interface and translates each request to whichever model is configured, so switching models does not require rewriting application code. The setup speaks to the gateway, the gateway speaks to the model, and the model can change without the setup noticing.
That this is real, not theory, is easy to check. One provider documents swapping between more than 250 models with a configuration change and no code rewrite, and reports that existing applications kept working unchanged after its catalog migration. Held as configuration, the model becomes the interchangeable part. The only question is whether you stand up and maintain that layer, or the platform does it for you.
Partly, and this is where honesty matters more than the pitch. Automatic absorption is already real. Deployments set to auto-update move to a newer default model version within two weeks of a change, so a provider can shift a production workflow to a newer model with no action from you.
The catch is that a better model is not automatically a safe one. Aggregate scores can rise while a specific workflow you depended on quietly regresses. The tracked example is stark: GPT-4’s accuracy on identifying prime numbers fell from 84 percent to 51 percent between March and June 2023. The users most exposed are the ones who built workflows around a specific output pattern. This is why teams now rerun a golden set of tests after every model change, because provider updates ship more often than internal release cycles and quietly shift behavior.
So the workflow gets the upgrade automatically. Whether the upgrade actually helped it is a separate question, and the only reliable way to answer it is to have the effect of the swap written down where you can check it, rather than discovered the hard way.
A better model can silently regress a specific workflow even as the aggregate scores improve. The users most harmed are the ones who built around a specific output pattern.
TianPan.co, 2026
Future-proofing is not betting on the right model. It is arranging your setup so the model stops being a bet at all. The market is moving this way: analysts project that by 2028 about 70 percent of software engineering teams building multi-model applications will use AI gateway capabilities, so a team can adopt a better or cheaper model without refactoring each time one ships.
The durable arrangement has two halves. Hold the context and configuration separate from the model, so a new model is absorbed underneath the setup instead of breaking it. And log every run, so when the model changes you can read the effect instead of trusting that newer meant better. The first half makes the upgrade painless. The second keeps it honest. The open, model-agnostic architecture behind the first half is covered in the case for keeping your setup independent of any single model
On a do-it-yourself stack, you do. You stand up the gateway, keep the abstraction current, rerun the tests, and own every regression a provider ships. The alternative is a platform that absorbs that work inside the setup you run.
This is the separation Works is built on. The context and configuration it holds sit in a layer kept apart from the models underneath, so a new, better model is adopted inside the setup you already have with no rebuild and no re-learning. That is the pain reliever. The feature that delivers it is automatic model absorption: new models land inside the existing setup, and the setup you run stays put while the capability underneath improves.
The honest limit stays attached to the claim. Works does not re-test or gate a swap against your workflow. What it does is absorb the swap automatically and keep the record: every run is logged through Action Logging, so when the model changes underneath, the effect is in the execution log, checkable against what the workflow produced before. A regression shows up in the record instead of staying silent. That is absorption you can see, not a promise you take on faith.
As a reference, Machintel runs on Works: a new setup reaches first value in about 14 days, and because the context and configuration sit separate from the model, that same setup absorbs later model upgrades without a rebuild. The setup holds its value while the intelligence underneath improves, the through-line of Compounding AI. The same logic sits behind what a vendor shutdown actually costs and the running cost of the model treadmill counted now.
Absorb new AI automatically. Sign up for early access.
Only if they were wired straight to one model. When your context and configuration sit in a layer separate from the model, a new model is absorbed underneath and the prompts and workflows stay as they are. The redo is a symptom of tight coupling to a single model, not an unavoidable cost of a new one.
Not fully. A newer model can improve on average and still regress a specific workflow, and providers can auto-update a deployment within two weeks. Absorption is safe when it is checkable: the swap lands automatically and every run is logged, so the effect is in the record rather than discovered later.
No, and it is worth being precise. The platform absorbs the swap automatically so nothing breaks in your setup, and it logs every run so you can see and check the effect of the change. It does not run a regression gate on your behalf. The value is automatic absorption plus a checkable record, not a promised re-test.
Keep reading
Priority access and a two-year price lock on the seat price for signups before October 30, 2026. We admit new accounts every week.
Ten users or more? Talk to us.
