How do you switch model providers without starting again?

Most of what you built survives a switch, provided it lives outside the model: the brief, the sources, the bounds, the customer's limits, the record and your certification cases with their answer keys. What does not carry over is the evidence. The new model must be certified on the same cases before it keeps any depth.

What carries over and what does not?

If your controls sit in the left column, a switch is a few weeks of testing. If they sit inside prompts written for one model, or inside a provider's own agent features, a switch means rebuilding. That is the real cost of lock-in, and it is decided long before anyone wants to switch.

What are the steps?

1. Platform owner: confirms the agent's assets are model-independent. Brief, sources and bounds stored in your platform, not in a provider's console. Evidence: an inventory of the agent's bundle.
2. Risk and data protection: review the new provider. Where data is processed, what the provider may retain, and contract terms. Evidence: a signed review.
3. Agent on the new model, depth 1: runs the certification case set in a test environment. Evidence: scores per gate.
4. Process owner: compares scores with the current model's results, gate by gate, not as a single average. Evidence: a side-by-side comparison.
5. Agent on the new model, depth 1: shadows live work for at least one business cycle. Evidence: filed proposals compared with live outcomes.
6. Process owner: certifies the agent, then switches one capability at a time. Evidence: a certificate per agent, naming the model and version.
7. Platform owner: keeps the old provider connected until the new one has run a full cycle. Evidence: the date the old connection was removed.

Why recertify if the brief has not changed?

Because the same words produce different behaviour on a different model. One model may refuse more readily; another may fill gaps with plausible guesses. Those differences show up in exactly the gates that matter most: grounding, refusal and escalation. Our piece on whether switching model providers changes what an agent may do makes the case in full.

What does a switch look like?

Say a wealth manager's client service agent runs on one provider's large model at depth 3, drafting replies and updating contact details. The firm wants to move to a model it can host in its own region.

The team runs the agent through certification on the new model using the same 500 past cases. Contact updates clear every gate. Drafting clears grounding and scope but scores lower on escalation: the new model handles complaints about fees as routine questions instead of passing them to a person. The brief gets a clearer escalation rule with examples, the agent is retested, and it clears.

The firm switches contact updates first, then drafting a month later. The old provider stays connected for a further month in case a rollback is needed. No bound, limit or owner changed throughout.

Which controls make a switch safe?

• Model version on every filed verdict, so you can tell which model made which decision.
• Shared case sets kept current, since they are the asset that makes switching cheap.
• Drift monitoring restarted from the new baseline after the switch. See what model drift is.
• One capability at a time, so a problem can be traced and undone.

The detailed controls are in switching model provider without losing control of an AI agent, and the wider sequence in our guide to deploying an AI agent.

Where Pryme fits

Pryme does not update model weights for a customer. Qualification changes the brief, sources, bounds and certification, which all sit in the platform. A new model behind an agent goes back through Attest on your cases, and its depth is set by that evidence and its role's ceiling, whichever is lower.