An agent applied a multi-file refactoring change to a production repository, and the team needs to roll back because the change introduced a runtime bug. The agent's logs show the refactoring completed successfully, but the team cannot identify what the state of the files was before the change. The agent did not record the original file contents. What should have been implemented before the agent began its changes?

Before any agent applies changes that modify existing state — especially multi-file refactoring — it must capture a reversible representation of the pre-change state. The two standard approaches are: (1) create a Git commit of the current state before making any modifications, so git revert or git reset can restore exactly that commit; or (2) record the original content of each file the agent intends to modify, stored as a rollback artifact alongside the task log.

Without a pre-change snapshot, rollback requires humans to reconstruct the original state manually — examining diffs, reading logs, or guessing — which is error-prone and slow in a production incident.

Option A (post-change validation) confirms the new state is what the agent intended, but does nothing to enable rollback to the previous state. Validation and rollback are separate capabilities.

Option C (notify the ops team) is a good practice for communication but does not address the missing rollback data. The team being notified does not know the original file state any better than the agent's logs show.

Option D (dry-run mode) is valuable for testing that the agent's logic produces the right changes before applying them, but dry-run does not capture the original state for rollback purposes. A dry-run shows what would change, not what to restore if the change needs to be undone.

Pre-change snapshots are a non-negotiable guardrail for agents with write access to production files.