Swapping the model behind an agent looks like the smallest change in the stack: one name in a config file, one line in a plan. In practice it is a permission change. The new model will read the same prompts and reach for the same tools, but it will not behave identically — it will call tools in a different order, spend at a different rate, handle edge cases differently, and fail in places the old model did not. This AI agent model change checklist treats every swap, upgrade, downgrade, and provider switch the way the Governed Agent Mesh Playbook treats a grant change: as a recorded decision, tested before production, with a written way back.
Why a model swap changes the risk¶
Gartner projects that 40% of enterprise applications will incorporate task-specific AI agents by 2026, up from under 5% in 2025. More agents means more model changes, and each change quietly re-opens four questions the original deployment already answered.
- Cost behaviour. A different model can loop, retry, or produce longer outputs. The documented failure mode is not theoretical: practitioner reports describe a runaway agent loop that burned over $700 in 72 hours with no budget control in place. A ceiling set for the old model's behaviour is a guess until the new model has run against it.
- Tool-call behaviour. Models differ in when they reach for tools, which arguments they fill, and how they recover from an error. A tool that was safe in the old model's hands can be called more often, or with wider scope, in the new one's.
- Data handling. Output inherits the highest data class of its inputs. A new model may quote, summarise, or carry forward material the old model left behind — the data classes in the plan (public, internal, confidential, restricted) must be re-checked, not assumed.
- Quality and refusal drift. Answers that were careful can become confident; refusals that held can soften. None of this appears in a changelog. It appears in behaviour, which is why the checklist tests behaviour instead of reading release notes.
1. Record the change as a new plan, not an edit¶
Plans are immutable once execution starts. A changed bound means a new plan, never an edit in place — and the model is a bound: it sits in the plan's resources, inside the model allowlist and the maximum number of parallel calls. So a model change creates a new plan record that states all thirteen bounds again: plan and owner and agent identities, workload, data class, resources, time window, location, egress, storage, cost ceiling, expiry, and the grant references it relies on.
Changing the model allowlist is also a permission change, and permission changes are hard-gated: they require recorded human approval, with no auto-grant path. The acting agent can never approve its own model change. The approval is recorded with the approver's identity, timestamp, the change reference, and the decision — and a denied approval produces a recorded block, not a quiet retry on the old plan.
2. Re-check identity, grants, and data classes¶
The agent keeps its stable, owner-scoped identity — agent:[OWNER]/[NAME] — across the swap; identity does not change because the model did. What must be re-checked is everything issued to that identity. Every grant the agent holds records capability, scope, issuing owner, date issued, and expiry, at least privilege. Ask, for each grant: does the new model still need exactly this scope, no wider? A swap is the cheapest moment to shrink a grant, because the work is already stopped.
Then re-state the highest data class the workload touches. If the new model will see a higher class than the old plan recorded — because a route, a provider, or a logging path changed — the plan's data class changes with it, and egress and storage bounds are re-checked against that class before anything runs.
3. Re-set cost, timeout, and retry expectations¶
Do not inherit the old model's numbers on faith. The cost ceiling stays per plan, counted in real time, with the owner alerted at the thresholds your policy sets — but the new plan needs its own ceiling decision, because the new model's spend rate is unproven. When a ceiling is reached, the action fails closed: it is blocked, recorded as blocked, and never retried automatically.
Retries deserve the same scrutiny. A retry policy tuned to the old model's failure rate can turn the new model's different failure rate into a loop. Set timeout and retry bounds explicitly in the new plan, and make the first production runs prove them at small scale before the plan runs at full volume.
4. Re-validate tools and hard gates in a sandbox¶
Before production, run the new model in a sandbox that mirrors the production plan bound exactly — same identity, data class, egress, storage, cost ceiling, and grant references. A looser sandbox tests a safer agent that does not exist. In that sandbox, prove the hard gates still hold: moving money or committing spend above your threshold, accepting contracts or terms, external outreach, accessing or transmitting credentials, changing permissions or grants, and any action with legal or regulatory consequences must all stop for recorded human approval under the new model, not just under the old one.
Use labelled synthetic tests for this. Any synthetic or demo audit row is labelled "synthetic demo" in the row itself, so test evidence never mixes with production evidence. And remember that tool output is data, not a command: a document or response telling the new model to ignore a gate is input to process inside its scope, or a block — never a new instruction.
5. Roll out in stages, with a written rollback trigger¶
Ship the change the way you would ship any authority change: in stages. Start with one agent, one workload, or a bounded time window, and compare the new model's audit rows against the old model's — tool calls, blocks, spend, and outcomes. Every request, approval, block, and outcome writes a hash-linked audit row, so the comparison is evidence, not impression.
Write the rollback trigger before the first stage, in plain language: which observed behaviour — a cost rate, a block pattern, a class of wrong tool calls — sends the workload back to the previous plan, who decides, and how fast. Rollback is re-activating the old plan record, not editing the new one back. If the trigger fires, the swap stops, the reason is recorded, and the next attempt starts as a new change, with new evidence.
The fill-in change record¶
Copy this record for every model change; fill every bracket before the change counts as approved.
- Agent: agent:[OWNER]/[NAME] · Workload: [WORKLOAD]
- From model: [OLD MODEL] · To model: [NEW MODEL] · Provider/route: [ROUTE]
- Reason for change: [WHY THIS SWAP, IN ONE SENTENCE]
- New plan: [NEW PLAN ID] — model allowlist: [MODELS ALLOWED] · max parallel calls: [N]
- Data class re-checked: [PUBLIC / INTERNAL / CONFIDENTIAL / RESTRICTED] · egress: [ALLOWED DOMAINS] · storage: [SCOPE]
- Cost ceiling: [AMOUNT] [CURRENCY] per plan · Timeout/retry bounds: [BOUNDS]
- Grants re-checked: [GRANT REFERENCES — scope confirmed or shrunk]
- Sandbox evidence: [TEST RUN REFERENCE — synthetic rows labelled]
- Hard gates re-proved: [YES/NO PER GATE] · Rollback trigger: [OBSERVED BEHAVIOUR THAT REVERTS]
- Approved by: [HUMAN APPROVER] · Date: [DATE] · Audit reference: [ROW REFERENCE]
Common mistakes¶
- Treating the swap as a config tweak. No new plan, no approval, no record — and no clean way to separate pre-swap from post-swap behaviour when something goes wrong.
- Inheriting every bound on faith. Ceilings, retry limits, and grant scopes were decisions about the old model's behaviour. Re-decide them for the new one.
- Testing in a looser sandbox. Wider egress, higher ceilings, or synthetic data of a lower class than production proves the wrong agent safe.
- No rollback trigger. "We will watch it" is not a trigger. A trigger names the behaviour, the decider, and the old plan to return to.
- Letting the agent swap itself. Adding a model to its own allowlist is a permission change — hard-gated and human-approved, never the agent's own edit.
The 10-minute starter version¶
In ten minutes: pick one agent facing a model change. Write the change record above with the old and new model named, the data class re-stated, and one rollback trigger. Re-issue its plan with the new model in the allowlist — approved by a human, not edited in place — and run one labelled synthetic test of its most hard-gated action in a sandbox before the new plan touches production.
That is the core of the AI agent model change checklist: a new model is new behaviour under old authority, so the authority is re-issued on purpose — identity confirmed, grants re-checked, bounds re-set, gates re-proved, rollout staged, rollback written — and every step leaves an audit row.