Written on the assumption that the best model available today will not be the best model available next quarter.
The durable advantage is not owning the right model. It is being built so that the question "which model" is answered again every few months, cheaply, without touching your data, your index, your policy or your records. This page explains the mechanism and states its limit.
The model market re-architects itself every few months. Capability moves between labs, prices fall in steps rather than curves, context windows change what is worth retrieving at all, and a model that was the obvious default in one quarter is a cost line in the next. None of that is a problem. It becomes a problem when an organization has built something whose shape assumes a particular model.
A platform vendor can argue the opposite, which is what makes this a claim rather than a truism. Their case is that depth beats portability: tune everything around one model and you get behaviour you could not otherwise reach. It is a real argument. It is also a bet that the organization making it will still want that model when the bet matures.
A twelve-month AI programme now spans two or three meaningful shifts in what is available. If adopting each one requires a project, the organization will adopt none of them and will explain that as discipline.
Nothing breaks when a better model appears. The system keeps working, slightly worse and slightly more expensive than the alternative, and the gap only shows up when somebody outside the organization does the comparison for you.
What holds value across those shifts is the environment, the index, the policy, the identity model and the records. The model is the most visible component and the most replaceable one, and those two facts are easy to confuse.
Your people do not talk to a model. They talk to the platform, which holds the identity, the quota, the content policy and the record, and which then calls a model. That indirection is the whole mechanism, and it is worth very little until you see what it makes cheap.
| Component | Moves when the generation model changes? | Why |
|---|---|---|
| Your documents and their storage | ✕No | They sit at rest in your account regardless of which model reads them |
| The knowledge index | ✕No | Built from the embedding model, which is a separate decision |
| Prompts and answer templates | △Reviewed | They usually carry over and are worth re-reading against the new model's behaviour |
| Roles, grants and quotas | ✕No | Identity and entitlement live in the platform, not in the model |
| The content policy | ✕No | Mandatory on every inference call by cloud identity policy, whichever model is called |
| Metering and audit records | ✕No | Settled against the provider's own record of the call; the model is a field in it |
| The embedding model | ✓Yes, if you change it | Changing it means re-indexing the corpus. This is the real coupling |
Generation and embedding are different decisions with different costs, and collapsing them is the most common way this argument is overstated. Switching what writes the answer is configuration. Switching what built the index is work.
Retrieval works because documents and questions are placed in the same space by the same model. Change that model and the existing index no longer belongs to it, so the corpus has to be re-indexed before the change is worth anything. That is a real cost, it is measurable in advance, and it is a reason to choose the embedding model with more care than the generation model.
The platform is built deeply on one cloud provider's services: the model service, identity, storage and the policy engine that makes the content policy mandatory. Composability is a claim about models inside that arrangement. It is not a claim about clouds, and we will not let the word stretch that far. What that means for the exit.
Residency is a real constraint on which models can serve you at all. Pinned to Canada, the in-region generation set is previous generation: Claude 3 Sonnet and Haiku, Llama 3 in two sizes, Mistral Large, Mixtral and Mistral 7B. Every current frontier model routes outside Canada. Residency is a genuine choice with a genuine capability cost, and anyone who tells you it is free has not read a catalogue. The residency page does the arithmetic.
Because switching is cheap, a new model does not need a business case. It needs an experiment with a bounded downside, which is a different and much smaller thing to ask an organization to approve. We treat each new tier as an option to be bought at low cost, exercised only on evidence, and allowed to expire without embarrassment.
Adaptive by design: a model market that re-architects every few months should be an advantage, not a threat.Why composability is a posture and not a feature
Here is the abstract argument with a real case attached. One vendor's newest frontier tier is only available if the account accepts provider-side data sharing with retention of up to thirty days. That is a genuine trade: the best current capability, against a retention posture that is wider than the default one every deployment starts with.
Those models are shown as unavailable until the client makes that election explicitly. Not hidden, not silently enabled when someone picks the newest name from a list. Widening the account's data-retention election is itself denied by cloud identity policy, so it cannot be done from inside the running product at all: it is a deploy-time change, made through a release, on a decision somebody signed.
It is the shape every model decision takes here. A capability appears, its cost is stated in terms the security owner recognizes, and the change is reviewed rather than absorbed. A reviewed change, never a silent upgrade. The same discipline is why the default posture can be stated plainly: prompts are not used to train models and are not shared with the model vendors, per the managed model service's terms.
Yes, and that is why it is a reviewed change rather than a toggle. Prompts and answer templates carry over but deserve re-reading, because models differ in how literally they follow an instruction. The platform makes the switch cheap; the review is what makes it safe.
No. Which models a deployment may reach is a deploy-time parameter, so a change arrives as a release against your deployment, from a tagged version, rolled deliberately and confirmed. Administrators cannot change it from inside the product either. How releases reach a deployment.
Open-weight models from several labs are in the catalogue and reachable through the same governed gateway, which is the sensible version of that question. Hosting your own weights on your own hardware is a different proposition: it adds a standing operations function for provisioning, patching and inference tuning that a small practice should not pretend to staff per client. We compared the two honestly.
It is generated on a date, and the one quoted on this page was generated on 5 September 2026. Refreshing it as providers change their lists is part of managed operations. Entitlement also varies by account, so what your deployment can actually reach is confirmed against your own account rather than assumed from ours.
The assessment includes which models can actually serve you under the residency and retention posture you need, rather than the list everyone quotes.