An agent proposes and stops. You approve. Everything it then changes is recorded first, and any of it can be put back.
The path a change takes
Proposal. A run examines your site and produces a list of what it would do and why. Nothing has happened. Each finding opens to show the reasoning and the page’s current metadata.
Approval. You approve, or decline. Declining is always available, including when a licence has lapsed — you should never be unable to say no.
Work. Approved jobs queue and run in the background. Before any job touches a post, that post’s current state is recorded against the run. If that recording fails, the edit does not happen.
Undo. Restore one post, a ticked selection, or everything the run touched.
What undo actually does
It restores, it does not delete
Restoring writes through WordPress, so every post it touches gains a revision. Undoing an agent never destroys what the agent did — both versions stay in your history.
It covers the featured image too
The image a run chose is replaced by the one that was there before. The newer image stays in your media library; undoing an edit is not a reason to delete a file.
A selection is checked
Ticking posts restores only those, filtered against what that run actually recorded. A post id from another run cannot be restored through the form.
Two shapes, two controls
A run that edited posts restores them. A run that only added rows — the librarian — has nothing to restore, so undoing it removes what it made. Those are separate buttons on purpose.
Why not just WordPress revisions
Revisions are a fine rollback until a site sets WP_POST_REVISIONS to false or caps it low. A restore that is only sometimes available is not a restore, so the prior state is recorded explicitly rather than assumed.
Did this answer it? Tell us if not and we will fix the article.