I got a call last week from a long-term client who’s obsessed with the latest tech. He’d seen the headlines about WordPress 6.9 Beta and heard whispers about “AI Abilities” being merged into core. He wanted to know if we could immediately swap out his custom OpenAI middleware for this new native Abilities API WordPress 6.9. I told him to hold his horses. While the server-side foundational work is officially in, this isn’t a “flip the switch” situation quite yet.
The Abilities API WordPress 6.9 milestone is a massive win for the Core AI team, but as a dev, you need to understand exactly what landed and what got left behind. My first thought was to start drafting the JavaScript components to hook into the Block Editor’s command palette. I figured if it’s in core, the client-side registration must be there too. Trust me on this: it isn’t. I spent a good hour digging through the beta source before realizing 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 thing that actually made the 6.9 beta deadline. This allows for registering and retrieving abilities—think of them as standardized descriptions of what an AI can actually do on your site. It’s the “source of truth” now. However, the front-end code is currently in a bit of a transition. The team decided to move the client-side code to the Gutenberg repo to leverage the existing infrastructure there, which makes sense, but it means your dreams of a native “AI-powered” block interface are still a few sprints away.
If you’re looking to play with this in your local environment, you’ll be working primarily with the PHP side of things. Here is a simplified look at how you might register a custom ability using the new patterns we’re seeing 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 mentioned in the latest Core AI check-in is the work on the MCP (Model Context Protocol) Adapter. There was a major refactor (PR #48) that just merged. It’s currently in that “messy but functional” stage where follow-up testing is critical. I’ve seen these large refactors break legacy integrations before, so if you’re using the experimental AI plugins, keep an eye on those version 0.3 tags. You can read the full technical update at the official source on WordPress.org.
Why This Move to Gutenberg Matters
The consensus to move client-side code into the Gutenberg repository is a pragmatic choice. It ensures that AI features like the command palette or automated block styling have a direct line to the editor’s state. It’s a total nightmare trying to sync state between a separate feature plugin and the core editor, so centralizing the JavaScript side is the right move for long-term stability.
For those of us in the trenches, the immediate takeaway is clear: start testing the server-side registration now. Get your “Abilities” defined. But don’t go promising your clients a shiny new AI dashboard in 6.9 just yet. We’re still in the plumbing phase.
Look, this stuff gets complicated fast. If you’re tired of debugging someone else’s mess and just want your site to work with the latest core features without the headaches, drop my team a line. We’ve probably seen it before.
Are you planning to wait for the stable release, or are you already breaking things in the 6.9 beta?
Leave a Reply