Rollback is the corrective half of the drift problem: monitoring tells you a system has degraded, rollback is what stops the damage, by reverting to a pinned, previously verified version rather than trying to patch the live system while it’s still producing bad output. For a traditional application, that’s a familiar deploy-tooling exercise. For an agent, it’s harder, because the model underneath is often a vendor’s moving target rather than a build under your own control, and the “version” that needs pinning includes the model, its tools, its prompts, and its data sources together.
Most agent deployments don’t have a working rollback path on day one, because it’s easy to defer until the system that would need it hasn’t failed yet. That’s the wrong order: a rollback procedure discovered mid-incident is being invented under pressure, with no rehearsal and no confidence it restores the known-good state. Detection has the same trap. A fixed error-rate threshold catches an agent that broke outright, but the more common failure mode is a slow decline in quality that a static threshold misses for weeks.
The organisations that get this right treat rollback the way they’d treat a database restore: tested on a schedule, not assumed to work because it was written down once. A rollback plan that has never been executed is a hypothesis, not a plan, and the first time to find out it doesn’t work should never be during the incident it was built for.