AI can edit your live site now. Can it take it back?

Quietly, in the last few months, the thing everyone was waiting for happened. An AI agent can write to a WordPress site now. Not a staging copy, not a draft. Your actual live site. The Abilities API made it standard, MCP made it portable, WordPress.com made it native, and the page builders are racing to catch up. By the end of the year, a WordPress install that can't talk to an agent will feel like a phone without a camera.

I think this is good. I built a company on believing it. WordPress runs something like 42% of the web, most of it maintained by people who aren't developers, and giving those people an agent that can actually do the work is one of the more democratic things to happen to the platform in years.

But I've been watching how those of us building these tools choose to build them, and I want to say this while the norms are still soft enough to set.

Nearly all the energy is going into one question: can the agent do the thing. Can it build the page, create the post type, wire up the fields. The platform has done careful work on the gate in front of that too, permissions, approval, validation, making sure the agent is allowed to act and that the request is well-formed. That part is real, and I don't want to wave it away.

What almost nobody is building is what happens after the agent does something it was allowed to do, and it turns out wrong.

That's the half that decides whether any of this earns trust. The dangerous moment isn't the agent doing something it shouldn't, the permission check catches that. It's the agent doing exactly what you approved, on a live site, and the result being worse than you pictured. A field group deleted that turned out to be load-bearing. A global style rewritten across every template. A tangle of changes you can't unpick by hand. Permission doesn't help there, because the action was permitted. It just had consequences nobody saw coming.

For most of the tools shipping right now, the answer to "now what" is a recent backup, if you took one, and an afternoon you weren't planning to spend. Restoring a whole-site backup to undo one bad agent session is a sledgehammer where you needed tweezers.

We can do better, and I don't think it should be a competitive edge. It should be a baseline. Here's roughly what I think it looks like.

A snapshot before anything destructive, of structure and not just posts. The field groups, taxonomies and options that hurt most to lose and get backed up least.

A record of what changed that an ordinary person can read in a few seconds, not a wall of JSON.

An undo that still works two weeks later, not just in the same session.

And recovery from a whole tangled session in one move, not a heroic manual unpicking of each step.

None of that lives in a permission check. It's the layer above it, and right now it's mostly empty.

I'll be straight about my own corner, because a standard proposed by someone who doesn't meet it is worth nothing. Here is what Respira actually does today, in the shipped version, no rounding up.

Every page and post edit is snapshotted before and after, so any edit rolls back. A whole session of edits, or an entire saved workflow, undoes in one call. And deleting a custom post type, a taxonomy, an ACF field group or an option is reversible, because Respira captures a recovery point first. I tested that last part by deleting those things on purpose and bringing them back, then by trying to break the undo six different ways. Two of those attempts found real bugs, including one where the undo itself was destroying data in a specific sequence. I found them on a throwaway site because I went looking for failure instead of assuming success. Both are fixed.

And here is what it does not do, because the boundary is the whole point. It does not cover edits to existing structure, only deletes and creates. It does not snapshot arbitrary third-party plugin operations. Restoring reverts to the snapshot point, so work done after a bad session gets reverted too, though that's now itself recoverable. I would rather tell you exactly where the undo stops than imply it goes everywhere, because the moment you imply "undo anything" is the moment someone trusts it with the one thing it can't catch.

That precision is the actual product. In a space where an agent can now be handed the keys to a live site through plain conversation, the most valuable thing a tool can tell you isn't "trust me." It's "here is exactly what I protect, here is exactly where that stops, and here is how you check it yourself."

So this is the ask, and it isn't about my plugin. Treat coming back from a mistake as part of the job, not an afterthought. Describe what you've built in precise words instead of the confident ones that sell better. If you're building in this space, including the people I compete with, the recovery half is open ground and the platform is better for every one of us who builds it well.

The Abilities API gave us a shared answer for what an agent is allowed to do. We don't have one yet for how to come back when a permitted thing goes wrong. That shouldn't belong to one plugin. It should be something we agree on and hold each other to.

The fast half is mostly built. The careful half is the work that's left, and it's the half that decides whether people end up trusting any of us.

— mihai