A rollback returns a live system to the last known-good version after a bad change ships. It usually follows a deployment: a team pushes a new version, checkout stops working or a dashboard loads blank, and rollback puts the old working version back while everyone regroups. Needing one is normal. Having no way back is the real failure. It differs from a patch, which fixes the broken thing: often you roll back first, then patch calmly.
Editing a client proposal in a shared document makes this concrete. A big round of edits breaks the pricing section, deletes the signature block, and confuses the scope. You don’t keep typing frantically inside the broken version. You go back to the last clean version and regroup.
Why you care
Agents raise the stakes here because they change a lot quickly: files, configs, content, published pages. That speed is valuable, and it only works when you have a clean way back. Before risky changes, know your last known-good state, keep changes small enough to understand, and test in staging before the public version changes.