on March 31, the WordPress core team did something unprecedented. they pulled WordPress 7.0 back from Release Candidate, returned it to beta-style testing, and delayed the release indefinitely. the original date was April 9 at WordCamp Asia in Mumbai. the conference happened. the release did not.
Matias Ventura, the release lead, framed it as "weeks, not months." the revised schedule arrives by April 22, according to the WordPress Make Core announcement. community speculation puts the real release around mid-to-late May.
if you run an agency managing WordPress sites for clients, the delay matters. not because the timeline changes anything operationally for you this week. because it reveals something about what WordPress 7.0 actually is, what it won't solve, and what you can do in the meantime that you couldn't do a year ago.
this is the post i wish someone had written three days ago. i'm writing it now because the revised schedule lands Wednesday, and after that the news cycle moves on.
what 7.0 was supposed to ship
three headline features are on the line, beyond the real-time collaboration work that caused the delay:
the Abilities API in core. a standardized way for WordPress core and plugins to register their capabilities as machine-readable units that AI agents can discover. shipped experimentally in 6.9. becomes first-class in 7.0.
the MCP Adapter. a bridge that turns registered abilities into Model Context Protocol tools that any MCP-compatible AI assistant can call. Claude Code, Cursor, VS Code Copilot, the whole ecosystem.
the WP AI Client. a provider-agnostic layer that lets WordPress talk to Claude, OpenAI, Gemini, or any compatible model without plugin developers having to reinvent the auth and request plumbing every time.
these are the right moves. WordPress is getting the foundational AI infrastructure a platform of its scale needs. real-time collaboration is separate but central to why the delay exists. Automattic didn't want to ship the collaboration data model until they were willing to stand behind it for the long term. that's the right call. a rushed 7.0 patched over six months with breaking fixes would be worse than a clean 7.0 arriving six weeks late.
the delay isn't a failure. it's a quality decision.
what 7.0 won't solve
here's the part agencies need to understand before the new schedule lands.
the Abilities API + MCP Adapter work through WordPress core data structures. Gutenberg blocks, posts, pages, taxonomies, settings, users, comments, menus. the REST API extended and formalized for AI agent consumption. it's excellent for what it covers.
but WordPress is not uniformly Gutenberg. on the 601 sites connected to Respira right now, Elementor is 39% of the base, Divi is 18%, Gutenberg is 11%, and the rest spread across Bricks, WPBakery, Beaver Builder, Breakdance, Oxygen, Brizy, Flatsome, Thrive Architect, and a handful of other commercial page builders. that matches what the broader WordPress ecosystem looks like. commercial page builders are the majority surface on production agency sites, not the minority.
these builders store content in proprietary formats. Elementor uses a custom JSON structure. Divi 4 uses shortcodes with hundreds of module types. Divi 5 moved to a block-based architecture. Bricks has its own element tree. WPBakery embeds shortcodes in post content.
the Abilities API and MCP Adapter cannot read or write this content meaningfully. not because the core team is ignoring the problem. because builder-native content handling is architecturally out of scope for the core protocol. the REST API can pass you raw shortcode soup, but it can't validate that your AI-generated Elementor widget has the right structure. it can't tell you that a Divi shortcode needs specific attribute formats. it can't preserve a Bricks element hierarchy through an edit.
the industry has started noticing this gap. the Master Control Press team, who build their own MCP layer on top of WordPress core, published an analysis naming it directly. InfoQ's coverage of the WordPress 7.0 AI features references the same gap. the webhosting industry trade press has been writing about it for a month. every honest technical reading of WordPress 7.0's AI story arrives at the same conclusion: this is a big step for Gutenberg sites, and a neutral step for the 60-70% of WordPress that isn't Gutenberg.
which is most serious agency work.
what this means for the delay window
you have six weeks. maybe eight, depending on the revised schedule. during that window, most hosting companies are pausing their 7.0 migration readiness work. most plugin developers are holding new AI feature releases until core lands. most agency tech decisions about "when do we invest in AI tooling" are being deferred until the dust settles.
but the work doesn't pause for your clients. the e-commerce site still needs product updates. the law firm's practice pages still need seasonal refreshes. the nonprofit still needs the annual report on the site before the board meeting. AI tools are ready today. your clients' content work is ready today. the only thing pausing is the official WordPress AI infrastructure that's supposed to make this easier.
this is a window. a real one.
for agencies who want to be AI-assisted during the delay, there are three honest options.
option one: wait. don't start. use this window to research, prototype on a staging site, and plan your adoption for when the Abilities API + MCP Adapter land in 7.0 stable. this is the conservative path. it's legitimate. you trade six weeks of potential productivity for certainty about which infrastructure to build on.
option two: adopt what's shipping in core now. WordPress 6.9 has the Abilities API experimentally. the MCP Adapter has stable releases available. you can start exposing WordPress capabilities to Claude Code or Cursor today, working through the REST API layer. this works beautifully for Gutenberg sites. for page builder sites, you'll hit the gap i described above quickly.
option three: use an AI infrastructure layer that already works across page builders. this is what i built Respira for. across the last 146 days, Respira has connected 601 WordPress sites, processed 17,376 AI write operations across pages and posts, and written 1.79 million lines of code into production WordPress with duplicate-first safety on every edit. Claude Code accounts for roughly 90% of the traffic (9,774 events). Cursor, Codex, Gemini, and GitHub Copilot make up the rest. 234 tools across 12 page builders. when WordPress 7.0 lands stable, Respira's tools are already registered as WordPress Abilities, so they become discoverable through the official MCP Adapter too. one plugin, two discovery paths, one safety model.
i'm telling you about option three because it's what i build. you should read that as disclosure, not as a conclusion. the honest version of the analysis is: if you have clients on Gutenberg sites primarily, you can probably wait or use core 6.9 infrastructure. if you have clients on Elementor, Divi, Bricks, or any other commercial page builder — which is most agency portfolios — the delay window is long enough that you should at least run one site through a builder-aware AI layer to see what the workflow actually looks like before 7.0 ships.
the strategic question underneath the delay
zoom out and the 7.0 delay tells a bigger story.
Cloudflare launched EmDash the same week the delay was announced. it's a TypeScript CMS built on serverless architecture, AI-native from day one, positioned explicitly as "the spiritual successor to WordPress." Matt Mullenweg closed WordCamp Asia with a keynote about AI being central to WordPress's future. WordPress 7.0 is shipping the most architecturally ambitious release in its modern history: Abilities API, MCP Adapter, WP AI Client, real-time collaboration, DataViews admin redesign, all at once.
none of this is a coincidence. WordPress is making a sustained, serious investment in staying the default platform of the AI era. the delay isn't a sign of weakness. it's a sign that the team is unwilling to ship the future before they're ready to stand behind it. that's how a 22-year-old open-source project behaves when it takes itself seriously.
agencies who stay close to WordPress through this transition are betting correctly. agencies who are already using AI through safer, builder-aware layers are betting correctly with a faster timeline. agencies who wait six months to see how it all shakes out are betting correctly with more patience. none of these is wrong. the wrong move is treating the delay as permission to ignore AI until 7.0 is shipped and stable, because by then the capability gap between AI-assisted agencies and non-AI-assisted agencies will have widened enough that catching up becomes expensive.
what we're doing at Respira during the window
in the spirit of build-in-public, here's what i'm shipping in the next six weeks while WordPress core is stabilizing 7.0:
CLI for WordPress v0.1.0. shipped this weekend. npm-installable. 34 commands. 12 builders. anonymous reads on any public WordPress URL. try it: npm install -g @respira/cli.
Respira tools registered as WordPress Abilities. done. when 7.0 lands stable, Respira's page-builder-native capabilities are discoverable through the official MCP Adapter too. one plugin, two discovery paths, one safety model.
a more complete tool catalog page at respira.press/tools. 234 tools documented with their builder coverage, safety indicators, and comparison to what the Abilities API covers. for agencies evaluating AI infrastructure, this is the reference page i wish existed before i started building Respira.
ACF support expansion. Advanced Custom Fields is in most agency WordPress sites. 54 new ACF tools shipped yesterday in v6.6.0 — fields, repeaters, flexible content, options pages, and relationship operations. snapshot-backed, dry-run previewable, per-tier license gated.
a few WordPress 7.0 compatibility checks running in the plugin already, quietly logging how Respira's behavior differs when it detects a 6.9 vs 7.0 site. when 7.0 ships stable, we're ready.
if you're an agency making AI decisions during the delay window, reach out. email mihai@respira.press. book a 30-minute call. i'm not going to sell you something you don't need. the point of writing this is to be useful, not to close a deal by Wednesday.
Respira works today. WordPress 7.0 arrives in May. both are true. both matter.
if you take one thing from this post
the delay isn't about AI features. those are ready. the delay is about the real-time collaboration data model, which is a database architecture question unrelated to anything an agency using AI on client sites cares about. when WordPress 7.0 finally ships, it will ship with the Abilities API + MCP Adapter roughly as they are today. the delay isn't going to unlock additional page builder support in those APIs. that gap remains.
your decision as an agency isn't "should i adopt the WordPress 7.0 AI infrastructure." it's "during this window, do i start building AI-assisted workflows for the page-builder sites that make up most of my portfolio, or do i wait until 7.0 lands and then realize the official infrastructure still doesn't cover page builders and i need a third-party layer anyway."
i know what i'd choose. but i'm biased. read five other takes before you decide.
— Mihai
Brașov, Romania
April 20, 2026
Join the conversation
1 comment · Respira account