Rollback is the corrective half of the drift problem: monitoring tells you a system has degraded, rollback is what actually 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, not just one artefact.
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 actually 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.