Yes, with one condition: the model must be able to call tools in a structured way. An agentic operating system holds authority, limits and records outside the model, so the model becomes a replaceable part. What does not carry over automatically is trust. A new model has to prove itself on your cases before it keeps the old one's depth.
Why can the model be swapped at all?
Because nothing that matters for control lives inside it. In a governed design, the model proposes the next step and the operating system decides whether that step may happen. Role, permitted sources, the customer's limits and the record of every verdict all sit in the platform. The model never holds a credential, never sees a limit it could talk its way around, and never writes to the record.
That separation is what makes "any model" possible. If permissions lived only in a prompt, each model would read them differently and a swap would quietly change what your agents do. The longer argument is in what an agentic operating system does that a model provider does not.
What does a model need to work under an operating system?
Not every model is a good fit, even if the platform can technically connect to it. The practical minimum:
- Structured tool calls. The model must emit a named action with typed parameters, not free text that has to be guessed at.
- A large enough context window to hold the brief, the facts for the task and the results of earlier steps.
- Sensible refusal behaviour. A model that invents an answer rather than saying it lacks the facts will fail certification however good it is at prose.
- Acceptable hosting terms. Where the model runs and what the provider may do with your data are decisions for your risk and data protection owners, not the platform.
Open-weight and hosted models can both meet this bar. Size is not the test; behaviour on your cases is.
What does the platform layer have to do?
| The platform does | Why it matters for model choice |
|---|---|
| Translates each model's tool-call format into one internal action format | Bounds and records stay identical whatever model proposed the action |
| Records which model and version produced each proposal | You can tell, later, whether a decision came from the old model or the new one |
| Keeps credentials and limits out of the model's context | A weaker model cannot leak or bargain over what it never saw |
| Routes different capabilities to different models if you choose | A small model can classify while a larger one drafts |
| Requires certification to be re-run after a model change | Depth reflects the model actually in use, not the one that was tested |
The last row is the one teams skip. A certificate describes how an agent behaved on your cases with a particular model behind it. Change the model and the certificate describes a different agent.
What happens in a real model swap?
Take a regional insurer's claims-summary agent that runs on a large hosted model at depth 2: it drafts summaries and a handler sends them. The team wants a smaller model they can host themselves, to cut cost and keep claim files in their own network.
They point the agent at the new model in a test environment and re-run certification on a few hundred past claims. It clears grounding and scope comfortably. It fails the refusal gate: on claims with missing medical reports, it fills the gap with a plausible guess instead of flagging it. The swap waits. The team adds a rule to the brief that missing documents must be named, re-runs, and the agent clears. Only then does the new model go live at depth 2. At no point did the role, the limits or the record change.
What controls make model choice safe?
- Treat any model change, including a version update from the same provider, as a change that requires recertification.
- Keep the model's version in every filed verdict.
- Re-run the cases after a swap and read the stable gate: a new model can answer the same question differently from one run to the next.
- Never let a model's own claim of confidence substitute for a bound. Confidence is an output, not a control.
If you want a list you can test vendors against, the agentic operating system requirements checklist includes model-independence checks. The wider picture of how the layers fit is in the governed agentic operating system guide.
Where Pryme fits
Pryme never updates model weights for a customer. Qualification changes the agent's brief, sources, bounds and certification, all of which sit outside the model. That is what lets you change model without rewriting your controls. A new model behind an agent should go back through Attest on your cases before you trust the depth it held before.
Questions people ask
Can different agents in the same business use different models?
Yes. Because bounds and records are held in the platform, one agent can run on a small fast model and another on a large one. Each is certified on its own capabilities with the model it actually uses.
Does using an open-weight model make governance easier?
It changes where the model runs, not what has to be governed. You gain control over hosting and data, and take on patching and capacity. Authority, limits and records still need the same layer above the model.
What if a model provider updates the model without telling us?
Pin versions where the provider allows it, and record the version reported with each response. If behaviour shifts, drift monitoring should catch it, and a failed certification run drops the agent to the lowest depth until it clears again.