WordPress and AI just entered a new phase. Officially.

TL;DR: WordPress.com launched AI editing for hosted Gutenberg sites. I released Respira for Wordpress 5.0 Haven for self-hosted builder sites. 19 tools vs 103 tools + instant roll back + woo-commerce & 11 page builders support.

There's an old parable about two builders working on opposite sides of the same mountain. Neither can see the other. Both are digging toward the center. One morning, they break through and realize they've been building the same passage from different directions.

Today felt like that.

I.

WordPress powers roughly 42.5% of the web. For twenty years, most of those sites have been managed the same way: you open the dashboard, click through menus, edit fields, and press publish.

The tools changed. The interaction model didn't.

Gutenberg replaced the classic editor. Page builders like Elementor and Divi added drag and drop. But the basic flow stayed the same: human opens interface, human makes changes, human saves.

Today, that started to change.

Two different teams shipped two different products that break the model in the same direction: you talk to your site, and it changes.

II.

The first launch came from Automattic.

WordPress.com flipped the switch on write-capable MCP tools for paid sites, which means AI agents like Claude, ChatGPT, and Cursor can now create and edit content through conversation. You can ask for a draft, a new page, taxonomy changes, comment management, or media metadata updates, and the agent handles the work after asking for approval.

There are nineteen new write tools in total. The system also reads the site's design language, colors, fonts, spacing, patterns, so the result looks like it belongs there.

It is a clean implementation, and for WordPress.com users it meaningfully reduces the distance between intention and publishing.

III.

The second launch was mine.

I shipped Respira for WordPress 5.0 Haven on the same day.

I build Respira, so this is not a neutral review. But the contrast matters, because these two products solve different parts of the WordPress world.

WordPress.com starts from a controlled platform. Respira starts from the messier, more interesting side of WordPress: self-hosted sites, mixed hosting setups, custom themes, and page builders with wildly different internal formats.

The difference is easier to show than explain, so let me start with a story.

IV.

A few weeks ago, a user sent me a message after approving a page edit through Respira.

The page was in their header menu. When they approved the duplicate, the original page went private. The menu link broke. Visitors clicked the header and landed on a 404. That is the kind of bug that makes people uninstall software. Not because it is especially complex, but because it violates a promise. The workflow that is supposed to keep your site safe becomes the thing that breaks it.

I fixed the immediate issue. Merge mode now writes the duplicate content back into the original post, preserving its ID, URL, and every reference pointing to it.

But that fix exposed the bigger problem.

Using Respira myself, I noticed I had started skipping the duplicate workflow when I wanted speed. I would tell Claude to edit the live page directly, because it was faster and usually good enough.

And when I did that, there was no real way back.

WordPress revisions store the title, content, and excerpt. But builder data, the Elementor layout, the Divi modules, the Bricks elements that define how the page actually works, often lives outside what revisions capture.

So I built the undo button.

V.

Every WordPress edit done through Respira for WordPress now creates a full-fidelity snapshot automatically.

Not just the post content. The builder payload, metadata, custom fields, and the pieces WordPress revisions usually miss. The snapshot is compressed, hashed for fast comparison, and stored in a dedicated table.

There's a new Changes page in the admin dashboard. Every post with Respira activity gets a timeline: pending duplicates at the top, full version history below. You can preview diffs between any two states and restore with one click. The restore itself creates a safety snapshot first, so even undoing an undo is possible.

Pinned versions survive all cleanup. Star a version to keep it forever. The state right before a redesign, the last version a client approved, whatever matters to you.

And every write operation through MCP or WebMCP now auto-snapshots before mutating. The AI can edit freely. The safety net catches everything.

That's Respira 5.0 Haven. The name felt right. A haven is a safe place. That's what the undo button provides.

VI.

So yes, these are two launches in the same category. Both let AI agents write to WordPress.

But they come from opposite constraints.

WordPress.com starts from the platform side. They control the hosting, the editor, the account system, and the theme layer. They can offer a toggle because they own the full stack. Their design-aware writing works cleanly because the design system is already theirs. Their write tools fit naturally because Gutenberg is the native editor.

Respira starts from the other side: self-hosted WordPress.

That means different hosts, different themes, different plugins, and eleven different builders, each with its own content format and internal logic. Some store layout as JSON. Some use shortcode trees. Some hide critical structure in meta fields. There is no single design system to read and no universal content format to trust.

Teaching an AI agent to work safely across that terrain has been my obsession for the last four months.

VII.

The difference becomes obvious the moment you try editing a builder site through the REST API.

With Gutenberg, you usually get structured blocks back. You can read them, modify them, and write them back in a fairly direct way.

With page builders, the page often looks editable until you realize the real layout data lives somewhere else.

Elementor may keep the real structure in post meta. Divi relies on shortcode hierarchies. Other builders have their own storage models and schemas. The page you see in the editor is not always the page the API gives you.

That is the problem Respira solves.

Not “write some text into WordPress.”
Write natively into the builder the site already depends on.

VIII.

I could keep describing the technical problem. Or I could show you what it looks like when it's solved.

After I finished the release, I wanted to test that claim properly.

So I sat down with Chrome 146+, the Claude browser extension, and a WordPress site running Divi 5. I gave Claude one prompt: create a stunning Divi5 landing page that shows what Respira can do, explain how it was built, and document the tech stack behind it.

One prompt. One conversation. No manual code. No dragging modules around in the visual builder. No copying layouts from somewhere else.

Claude read the site context through Respira's MCP tools. It understood the Divi 5 format through Respira. It designed a multi-section page with a hero, capability sections, a tech stack explanation, a build timeline, micro interactions + animations, and calls to action. Then it wrote the page and published it live through the builder's own structure.

The result is a native Divi 5 page, not pasted HTML pretending to be one.

The result is at mihai.love/respira.

The page documents exactly how it was made, including the prompt that created it. This is a native Divi 5 page. Not Gutenberg blocks dropped into a Divi site. Not HTML injected into the post body. Actual Divi 5 sections, rows, columns, and modules, placed through the builder's own content format. The kind of page that would take a designer a full day to build manually.

That is what builder-specific intelligence looks like in practice. The AI is not just filling a text field. It is speaking the builder's language.

IX.

There's a question underneath both of today's launches that I think about a lot: what happens when the AI gets it wrong?

For Respira, I needed a different safety model.

When an AI agent edits a live Elementor or Divi landing page, “it starts as a draft” does not really apply. The thing being changed is often already live. And asking permission is only the first layer of safety. You also need to see what changed, compare it to what came before, and restore the full state in one click, including the builder data WordPress revisions do not preserve.

That is the gap Haven fills.

This is not a criticism of WordPress.com's approach. It is a difference in terrain. Hosted Gutenberg sites and self-hosted builder-heavy sites need different kinds of safety. The safety infrastructure has to match the terrain.

X.

I did not plan to launch Haven on the same day as WordPress.com.

The work was already underway because of that broken-menu bug and the product question behind it: if Respira already captures full-fidelity snapshots, and WordPress already has native revisions, why can't users actually see and use that history properly?

So I built the missing layer: merge mode that preserves identity, a Changes page that exposes the timeline, and automatic snapshots around every write action.

Then WordPress.com shipped their launch, and I pushed mine too.

I think the overlap says something real about where WordPress is headed. The infrastructure is converging. Core AI work is moving. MCP is no longer a side conversation. The question is no longer whether WordPress will be editable through agents. It already is.

The infrastructure is converging. WordPress 7.0 ships April 9 with a “Try AI” callout on the about page. The WordPress/ai repo on GitHub has commits from hours ago. The Abilities API is maturing in core. The MCP Adapter is being actively discussed as a standalone plugin or as part of the AI experiments plugin.

I commented on PR #152 this week with technical notes from running 100+ WordPress Abilities in production. I've been talking with other plugin developers about how to register abilities well. I'm watching the core-ai team build the foundation in real time, and I'm trying to make sure page builder sites can be part of it.

XI.

So where does this leave us?

If your site is on WordPress.com and you use Gutenberg, today is a good day. Toggle on the write tools and start talking to your site. The onboarding is smooth and the design awareness is a smart touch.

If your site is self-hosted and built with Elementor, Divi, Bricks, or the rest of the builder ecosystem, this is also a very good moment. Respira 5.0 Haven gives you 103 tools, builder-aware editing, and a rollback model designed for live site work. Every change is visible. Every restore is reversible.

If you're a developer or agency managing multiple sites across both worlds, you probably need both. WordPress.com MCP for your hosted clients. Respira for your self-hosted clients. The tools don't conflict because they serve different sides of the ecosystem.

And if you were still wondering whether AI agents editing WordPress is real or just another hype cycle, today answered that.

Two teams shipped from opposite sides of the ecosystem on the same day.

The tunnel is almost through.

The detailed side-by-side comparison with scenario breakdowns: respira.press/blog/respira-vs-wordpress-com-mcp

The full 5.0 Haven release story: respira.press/releases/5.0.0

WordPress.com's announcement: wordpress.com/blog/2026/03/20/ai-agent-manage-content

I'm Mihai. I build Respira from Brașov, Romania. Solo founder, father of two, and still very interested in making WordPress less painful to change.

If you are working in the WordPress AI space, say hi in #core-ai on WordPress Slack.