A client I have worked with for years called me last week. He follows every release note, and he had seen the headlines about WordPress 6.9 Beta plus the whispers about “AI Abilities” being merged into core. His question: could we rip out his custom OpenAI middleware and switch to the native Abilities API WordPress 6.9 instead? I told him to wait. The server-side foundation is in, but this is not a flip-the-switch upgrade yet.
The Abilities API WordPress 6.9 milestone is good news for the Core AI team, but as a dev you need to know exactly what landed and what did not. My first instinct was to start drafting the JavaScript components that hook into the Block Editor’s command palette. If the API is in core, the client-side registration must be there too, right? It isn’t. I spent a good hour digging through the beta source before I worked out that the JS portion has been deferred to the Gutenberg repository.
The server-side reality of the Abilities API
Right now the server-side implementation is the only part that made the 6.9 beta deadline. You can register and retrieve abilities, which are standardized descriptions of what an AI can actually do on your site. That registry is the source of truth. The front-end code, though, is mid-transition. The team moved the client-side code to the Gutenberg repo to reuse the infrastructure already sitting there. Sensible enough, but it also means a native “AI-powered” block interface is still a few sprints out.
If you want to poke at this in a local environment, you will be working almost entirely on the PHP side. Here is a stripped-down look at registering a custom ability using the patterns showing up in core development:
/**
* Registering a custom 'Ability' for an AI agent.
* This is based on the emerging patterns in WordPress 6.9.
*/
function bbioon_register_product_optimizer_ability() {
if ( ! function_exists( 'register_ai_ability' ) ) {
return;
}
register_ai_ability(
'bbioon/optimize-product-description',
array(
'description' => __( 'Optimizes WooCommerce product descriptions for SEO.', 'bbioon' ),
'parameters' => array(
'product_id' => array(
'type' => 'integer',
'required' => true,
),
),
'callback' => 'bbioon_handle_product_optimization',
)
);
}
add_action( 'init', 'bbioon_register_product_optimizer_ability' );One of the more interesting technical bits in the latest Core AI check-in is the work on the MCP (Model Context Protocol) Adapter. A large refactor (PR #48) just merged. It sits in that messy but functional stage where follow-up testing matters. I have watched refactors this size break legacy integrations, so if you run the experimental AI plugins, keep an eye on those version 0.3 tags. The full technical update is on WordPress.org.
Why the move to Gutenberg matters
Moving the client-side code into the Gutenberg repository is a pragmatic call. AI features like the command palette or automated block styling get a direct line to the editor’s state. Syncing state between a separate feature plugin and the core editor is miserable work, so keeping the JavaScript in one place is the right choice for stability.
For anyone doing the actual work, the immediate job is to test server-side registration and get your abilities defined. Just don’t promise a client a shiny AI dashboard in 6.9. We are still at the plumbing stage.
This stuff gets complicated fast. If you are tired of debugging someone else’s mess and just want your site to keep working with new core features, drop my team a line. We have probably seen it before.
Are you waiting for the stable release, or are you already breaking things in the 6.9 beta?
