The WordPress Abilities API made it into 6.9 Beta 2, which after months of watching the Core-AI work is good news. What landed is not quite the prototype some of us have been reading in the repository, though. The JavaScript registration ended up somewhere else, and that is worth knowing before you start refactoring plugins around it.
Why the WordPress Abilities API in 6.9 Beta is only half there
The server-side half is in Core and holding up, and the team has already moved on to community testing, so the original standalone repository is probably headed for the archives. That is the usual path for a Core feature: build it as a feature plugin, iterate, merge. The point of all of it is a machine-readable way for plugins and themes to declare what they can do, which gives an AI agent a capability map instead of a guess.
The catch is the JavaScript ability registration, the part that lets the front end interact with these definitions. It missed the Core merge deadline. Rather than hold the whole API back, the team moved JS registration into the Gutenberg repository, where it will ship as a standalone NPM package. In practice you will be pulling in a package for now instead of leaning on a global Core JS variable.
<?php
/**
* Registering a server-side ability in WordPress 6.9
*/
function bbioon_register_ai_summary_ability() {
if ( ! function_exists( 'register_ability' ) ) {
return;
}
register_ability( 'bbioon/content-summarizer', [
'label' => __( 'Content Summarizer', 'text-domain' ),
'description' => __( 'Generates a 2-sentence summary of any post.', 'text-domain' ),
'category' => 'content',
'capabilities' => [ 'edit_posts' ],
] );
}
add_action( 'init', 'bbioon_register_ai_summary_ability' );The AI Experiments plugin moves past scaffolding
Core gets the API; the AI Experiments plugin is where the features live. A 0.1.0 release is close, and it brings a working admin settings screen plus the first experimental feature, title generation. If the absence of a standard UI for LLM credentials in WordPress has been annoying you, this is the project to watch.
I have opened plenty of AI plugins that hardcode an OpenAI key into a settings field and call it an integration. AI Experiments is at least trying for an architecture that survives different environments. They also merged a Playground link for PR testing, which more plugin developers should copy; reviewing a pull request you can click into is a different experience entirely.
WP AI Client puts the server first
One detail from the latest check-in stuck with me: the WordPress AI Client is being pushed toward a 0.1.0 that covers server-side LLM querying only. The REST endpoints for client-side, JS-based querying are deliberately deferred, so direct browser-to-LLM calls through the official client are off the table for now.
That ordering makes sense. A response handled on the server can be validated and passed through hooks before it reaches anyone’s screen, and the credentials never leave the host. Client-side AI calls without a solid transporter behind them tend to end in race conditions or leaked credentials.
If WordPress Abilities API work is eating your dev hours, I take that kind of job on. I have been wrestling with WordPress since the 4.x days.
The MCP Adapter refactor
The MCP Adapter is worth watching too. Its 0.3.0 refactor was big enough that the team says 0.1.0 is effectively unusable now, because the shape of the abilities changed underneath it. That is what early Core development looks like. Anything you built on the early MCP prototype needs its dependencies updated, or the integration logic will stop lining up.
The WordPress Abilities API is the base layer for whatever AI work Core does next. Its job is to give WordPress a common language for describing what your code can actually do, which is a more useful problem to solve than bolting another chatbot onto the admin.
