What actually changes
The phrase "the model changed" covers several different events, and they arrive through different doors:
- A model version is upgraded, and the version you tested is replaced by a newer one.
- A model version is retired, and anything still pointing at it has to move.
- A platform changes which model is the default for a feature, and anything left on the default moves with it.
- The safety and filtering behaviour around the model is adjusted, so what the agent will and will not answer shifts.
- Someone on your side changes the model deliberately, for cost or latency or capability, and treats it as a configuration tweak rather than a change to the agent.
Only the last of these is yours to schedule. The rest happen on somebody else's calendar, and the notice, where there is notice, reaches a platform administrator rather than the person who signed the agent off.
Why this is not like any other change you manage
Every other change to an agent leaves a mark somewhere you already look. A widened permission shows up in the permission set. An edited instruction shows up in the agent builder. A changed flow shows up in your deployment history. A model change leaves no mark in your org at all. There is no diff to review, because none of your metadata moved. There is no deployment record, because nobody deployed. If your review process is to look at the configuration and judge whether it still looks right, a model change is invisible to it by construction, and the configuration will look right forever.
What tends to move, and why a launch test does not cover it
A newer model is not simply a better version of the one you tested, from your agent's point of view. The differences are rarely a clean break. They show up as changes of degree:
- How literally it follows an instruction, especially a negative instruction about what not to do.
- How readily it refuses, which can move in either direction: an agent that starts declining work it used to do, or one that stops declining work it should.
- How it handles an ambiguous request, which is exactly where the handoff to a human is supposed to trigger.
- Which action it picks when more than one could apply.
- The length, tone and confidence of what it says to a customer.
None of that reliably produces an error. The agent keeps working, no alert fires, and the first evidence is usually an interaction somebody happens to read. A launch test cannot cover it either, because a launch test is evidence about the model that was running that week.
Put the model in the row, and treat a change as a change
Two habits make this tractable, and neither requires you to predict a vendor's roadmap:
- Record which model each agent runs on, in the same row as its owner and its approval, so the question of what is running underneath has an answer rather than a guess. This is the field most often left blank when you build the inventory, and the one that dates fastest.
- Classify a model change as a material change, in the same category as a widened permission or an edited flow, so it triggers re-inspection instead of a note in a release channel. What else counts as a material change is listed in the FAQ.
Check behaviour, not configuration
The check that catches a model change has to be written against what the agent is supposed to do, and run against what the agent actually did. Checks compiled from a signed approval survive a model swap, because the approval says what the agent may and may not do rather than what one model happened to produce. Checks written against expected outputs do not survive it. They were authored by looking at one model's phrasing, and the first upgrade turns them into false failures that people quickly learn to ignore. That distinction is the whole point of inspecting against the approval rather than watching a dashboard.
What this looks like in practice
In Huscribe, the model behind each agent is part of the register row, and a model change is one of the material change events that triggers a run. The checks compiled from the signed approval run again against what the agent actually did, and the run issues a report. If the agent still does what was approved, the row says so, with the date and the evidence behind it. If it does not, you get a finding: the check that failed, the evidence quoted from the report, the proposed cause and the smallest change that would pass. The owner decides, your team ships it, and the next report confirms the repair. The full loop is in how Huscribe builds and inspects Salesforce agents.
The question worth asking now
You do not need to wait for a vendor announcement to find out where you stand. Take the agent that matters most and ask which model it is running on today, and whether that is the same one it was running on when somebody approved it. If nobody can answer the first part, the answer to the second is no.