Not because anyone decommissioned it. Because the model underneath it was updated — by the provider, on the provider's schedule, for the provider's reasons. Same agent name, same integration, same approval on file. Different behavior.
This is not hypothetical. Model providers ship updates continuously; hosted models are routinely upgraded, aliased, and retired underneath the applications that call them. We've experienced it firsthand in our own operations: a provider silently repointed a model alias to a newer model with different characteristics, and a production pipeline's behavior — and its cost profile — changed overnight without a single line of our code changing. We caught it because we monitor. Most teams would have found out at invoice time, or worse, at incident time.
The point-in-time review was built for point-in-time software
Traditional enterprise review works because traditional software is static between releases. The binary you assessed in March is byte-identical in June; change control exists precisely so that anything that alters behavior passes back through review.
AI agents break both assumptions at once:
- The substrate drifts. Model updates change reasoning, refusals, tone, tool-use patterns, and failure modes — with no change to your code and no entry in your change log.
- The context drifts. Agents act on live data, evolving prompts, growing memory, and other agents. An agent that was safe in its March environment can be unsafe in its June environment without either the agent or the model changing.
A point-in-time review of an agent is a photograph of a river. Accurate the moment it was taken, and increasingly fictional every day after.
What continuous assurance actually looks like
Monitoring an agent is not uptime monitoring with a new name. The assurance question isn't “is it running?” — it's “is it still the thing we approved?” That decomposes into a concrete checklist:
- Behavioral baselines: capture the agent's decision distribution on a reference workload; re-run and diff on a schedule and on every known model update. Drift beyond tolerance = automatic flag, before users notice.
- Substrate watch: track the actual model versions serving your agents — not the alias, the resolved version — and treat provider-side updates as change events requiring re-verification. Never pin production to a floating “latest” alias without a gate.
- Authority audit: continuously verify the agent's effective permissions against its approved scope. Permission creep is the agent-world equivalent of segregation-of-duties drift — and it accumulates just as silently.
- Decision-log integrity: the log must be complete, tamper-evident, and reviewable — because when something does go wrong, the log is the difference between an incident review and an unanswerable question.
- Cost and cadence anomalies: an agent that suddenly thinks longer, calls more tools, or spends more per task is telling you something changed. Cost curves are behavioral telemetry, not just finance data.
The output of all this isn't a dashboard for its own sake. It's a living trust score — one that decays when evidence goes stale and recovers when re-verification passes — plus an evidence trail that lets the agent stand in front of the same review gate, any day of the year, and pass.
The uncomfortable summary
If your assurance model for AI agents is an annual review, your real assurance is this sentence: “we believe the provider hasn't changed anything important since we last looked.” No auditor would accept that sentence about your financial controls. There is no reason to accept it about software that acts with delegated authority.
Point-in-time review answers “was it trustworthy then?” Continuous monitoring answers “is it trustworthy now?” Only one of those is a question your customers are asking.