WordPress 7.0 is just around the corner, and the latest news on WordPress AI Features makes one thing clear: the architecture is shifting from “experimental” to “infrastructure.” If you have been following the weekly contributor summaries, you know we are in a high-stakes phase where decisions made today will dictate how AI agents interact with our sites for the next decade.
I’ve seen plenty of core cycles where things get messy right before a major release. This time, however, the team is being remarkably pragmatic about reduced contributor availability. Instead of hitting the brakes, they are moving forward with “reversible decisions”—a strategy every senior dev should keep in their back pocket when the roadmap gets tight.
The MCP Adapter: Going Standalone
One of the biggest architectural pivots discussed this week is the distribution of the Model Context Protocol (MCP) adapter. Initially, there was talk about how to bake this in, but the decision is now final: it will be a standalone WordPress.org plugin.
This is a smart move for two reasons. Specifically, it allows for faster iteration cycles outside of the Core release schedule. Furthermore, it simplifies dependency management. By using the official plugin repository, developers can leverage existing installation workflows without forcing a massive dependency on every site that isn’t ready for AI-driven “abilities” just yet.
If you’re curious about how these WordPress AI Features are evolving, you should check out my previous breakdown on WordPress 7.0 AI Features and the MCP Interop.
Registering Abilities: The Right Way
A “gotcha” I see often is developers trying to hack together their own AI interfaces. With the new Abilities API, you should be registering your functions so they are discoverable by the MCP adapter. Here is a quick look at how you might register a custom ability in the upcoming ecosystem. Note the use of the public meta flag—essential for visibility.
<?php
/**
* Register a custom ability for the WordPress AI ecosystem.
*/
function bbioon_register_custom_ai_capability() {
// Check if the Abilities API is available
if ( function_exists( 'register_ability' ) ) {
register_ability( 'bbioon/process-order-logic', [
'label' => __( 'Process Specialized Order', 'bbioon' ),
'callback' => 'bbioon_handle_ai_order_logic',
'meta' => [
'public' => true, // Makes it discoverable by MCP
],
] );
}
}
add_action( 'init', 'bbioon_register_custom_ai_capability' );
/**
* The callback function executed by the AI client.
*/
function bbioon_handle_ai_order_logic( $args ) {
// Logic for processing order goes here
return [ 'status' => 'success', 'message' => 'Order logged.' ];
}Navigating the Contributor Gap
We need to talk about the project’s velocity. Several leads are tied up with high-priority initiatives for the next month, which usually spells disaster for a release candidate. Consequently, the team has delegated decision authority to active maintainers. This is a classic refactor of project management: keep the pipes moving, document every choice, and revisit “irreversible” changes when the full brain trust is back.
For those interested in the UI side of things, the WordPress AI Plugin 0.8.0 release is still on track for April 23rd, focusing heavily on content resizing and request logging. These are the small, unsexy features that actually make a system production-ready.
Look, if this WordPress AI Features stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
Strategic Takeaway
The road to WordPress 7.0 is bumpy but technically sound. By separating the MCP adapter and focusing on reversible architecture, the team is ensuring that the foundation of WordPress AI Features isn’t built on a house of cards. Therefore, if you are a plugin author, now is the time to start auditing your code for potential “Abilities” and preparing for the standalone adapter’s release.
