Keep the agent's authority outside the model, so a switch changes how it reasons but not what it may do. Review what data the new provider will receive, run the new model in shadow, re-certify the agent before it acts above draft, and cut over one capability at a time. Every verdict records which model produced it.
What changes when you switch, and who owns the switch?
A model provider supplies the reasoning. It does not know your limits, your sources or who approves what, and it should not need to. If those live in prompts tuned to one model, a switch means rebuilding them and hoping. If they live in a separate layer, a switch is a change of engine under the same rules. That distinction is explained in what an agentic operating system does that a model provider does not.
Even with authority held outside, the new model will behave differently. It may follow instructions more literally, refuse more often, or reason at greater length, as a reasoning model does. Evidence earned on the old model does not transfer.
The platform team owns the switch. The data protection lead owns the review of what the new provider will see. Third-party risk owns the supplier assessment. Each process owner decides when their agent's capabilities move.
How do you switch, step by step?
- Platform team: confirm what lives outside the model. The brief, sources, connections, bounds and certificates should all be held by the platform. Anything held only in a model-specific prompt must be moved first. Evidence: an inventory of agent configuration with its location.
- Person, data protection lead: reviews the new data flow. What personal data will reach the provider, where it will be processed, how long it is kept, and whether it is used for training. The rules on this are discussed in GDPR and prompt data. Evidence: an updated record of processing and, where needed, an impact assessment.
- Person, third-party risk: assesses the provider. Security, availability, exit terms. For EU financial entities, DORA's ICT third-party risk rules apply to this decision. Evidence: a completed supplier assessment.
- Platform: route the new model in shadow. It answers the same live cases as the current model, at depth 1. Its outputs are recorded but never acted on. Evidence: paired outputs per case.
- Platform: run certification on the new model. Replay the agent's own past cases and score them against the same floor. Evidence: a certification run per agent, per model.
- Person, process owner: reviews the differences. Look for cases where the new model refuses, escalates or acts differently. Adjust the brief, not the bounds. Evidence: a change log.
- Platform: cut over capability by capability. A capability moves when the agent's certificate on the new model reaches the depth it needs. Until then, if it runs on the new model at all, it runs at draft. Evidence: routing configuration with dates.
- Platform: keep the old route available for a fallback period, then retire it and record the retirement.
| Step | The agent does | Depth | Stays with a person |
|---|---|---|---|
| Inventory | Nothing | none | Platform team confirms config location |
| Data review | Nothing | none | Data protection lead approves the flow |
| Supplier review | Nothing | none | Third-party risk approves the provider |
| Shadow | New model answers live cases, unused | 1 | Nothing |
| Certify | Replays past cases on new model | 1 | Owner reviews failures |
| Cut over | Acts on the new model | certified depth | Owner approves each move |
| Retire old route | Nothing | none | Platform team records retirement |
Which controls keep you in control, and what evidence do they leave?
Bounds are model-independent. The same limits, sources and approvals apply whichever model is behind the agent. Evidence: unchanged bound versions across the switch.
Certificates are per model. A certificate earned on one model does not carry to another. Evidence: separate certification runs.
Model recorded on every verdict. You must be able to say which model drove any decision. Evidence: model and version on each verdict.
Drift watched across the switch. Compare answers on the same cases before and after. Evidence: paired outputs from shadow and live.
Routing is explicit. If you use a model router to pick models per task, the routing rules are configuration with an owner and a history, not a black box. Evidence: router rules under version control.
What should you measure?
- Agreement rate in shadow, counted as cases where both models reach the same outcome, out of all cases compared.
- Refusal and escalation changes. A new model that escalates twice as often will flood approvers.
- Certification results, old and new side by side.
- Cost and latency per case.
- Personal data sent to the provider, by field, against what the review approved.
Where does it usually go wrong?
Prompts carried authority. Limits written into the old prompt do not survive translation to the new one. Move them into enforced bounds before switching.
Big-bang cut-over. Every agent moves on one weekend and nobody can tell which differences matter.
Certificates assumed to carry over. The agent keeps its depth on a model nobody has tested.
The data review is skipped because "it is only a model change". A new provider is a new processor.
No fallback. The new provider has an outage and agents stop. A tested route back, even at reduced depth, keeps operations running. The practical side of moving without rebuilding is covered in how to switch model providers without starting again.
Where Pryme fits
Pryme holds the agent's brief, sources, bounds and certificates outside the model, and never updates model weights for a customer. Attest re-runs certification on the new model against your own cases, with the stable gate among its seven gates, and every verdict records the model that produced it. The governed agentic operating system guide explains the separation.
Questions people ask
Do we have to re-certify every agent?
Every agent you want to run above draft on the new model, yes. An agent that only reads can often move with a shorter run, since a read cannot change anything.
Can different agents use different providers?
Yes. Bounds and records are the same either way. Keep the routing explicit so you always know which provider each agent uses.
Should customers be told the provider changed?
Your transparency duties depend on where you operate and what you have told customers before. Check your privacy notices with your data protection lead.