A client came to me last year with a big site and a pile of custom data. They wanted an AI assistant that could do more than answer questions. It had to check stock, update a customer’s address, even draft a blog post from a voice memo. I said that was fine. I would write some custom REST endpoints and hook them into a LangChain agent.
It went badly. Building a custom interface between an AI and your database is like letting a bull into a china shop and hoping it sticks to the blue plates. Three weeks went into a permissions layer whose only job was stopping the assistant from wiping the product catalog. It held up for about five minutes. Then a plugin update changed the endpoint structure and I was back where I started. More code was never going to fix that. What was missing was a standard, and that is what the WordPress Abilities API is.
Standardizing AI actions with the WordPress Abilities API
That is why the traffic in the #core-ai Slack channel is worth reading. At the bi-weekly meeting on October 16th, 2025, the team went over how far the Abilities API has to get for the WordPress 6.9 release. It is the groundwork for what the project calls “agentic” behavior in WordPress: plugins register their abilities, AI agents discover those abilities and use them safely, and nobody hard-codes a separate integration for every interaction.
The notes on make.wordpress.org show the team locking down hooks for the MVP. That matters more than it sounds. Hooks are what let a plugin ship features between core releases instead of waiting for the next one. Fourteen years of this work has taught me that an API nobody can extend is dead on arrival. The meta system and *_args filters on the table are what keep things flexible while core catches up.
They also went over the MCP (Model Context Protocol) Adapter, which is the bridge between WordPress and the AI models themselves. The split is sensible. The Abilities API only registers what a site can do, and the adapter decides what the AI gets to see. That keeps the feature creep that usually kills a new API out of the API itself.
What registering an ability actually looks like
Registration replaces the custom endpoint. You describe the function, the arguments it takes and the permissions it needs, and the AI reads that description instead of guessing. The example below is conceptual, a price update on a product, with everything prefixed so it stays out of anyone else’s way.
// Concept for registering an AI ability in WordPress 6.9
add_action( 'init', function() {
if ( function_exists( 'bbioon_register_ability' ) ) {
bbioon_register_ability( 'bbioon_update_product_price', [
'label' => __( 'Update Product Price', 'bbioon' ),
'description' => __( 'Updates the price of a WooCommerce product by ID.', 'bbioon' ),
'callback' => 'bbioon_handle_price_update',
'args' => [
'product_id' => [ 'type' => 'integer', 'required' => true ],
'new_price' => [ 'type' => 'number', 'required' => true ],
],
'capability' => 'edit_products',
]);
}
});
function bbioon_handle_price_update( $args ) {
$product_id = absint( $args['product_id'] );
$new_price = floatval( $args['new_price'] );
// Logic to update the product goes here
return [ 'success' => true, 'message' => 'Price updated.' ];
}The part I like is the “philosophy” approach. Writing down what the project believes, the way Tanstack does, is what stops the Abilities API from turning into a junk drawer for every experimental AI feature. I have watched experimental code reach production and produce a race condition in the middle of a high-traffic sale. Better to argue about the beliefs first.
Why these core AI updates matter for your site
If you run an agency or a large site, this changes the shape of your admin work. Users will stop clicking through menus and start stating intent, and the Abilities API is what turns that intent into a permitted action. It does not fix a messy site, though. An AI agent sitting on top of a mess just reaches the mess faster.
- Integrations stop being black boxes, because every ability is registered the same way.
- Permissions live in the registration itself rather than in a wrapper you bolt on later.
- An agent can query the API and see exactly which actions it is allowed to take.
- Code written against the Abilities API now still runs when 6.9 ships.
None of this stays simple for long. If you would rather not spend your week debugging someone else’s integration, send my team a note. We have most likely dealt with your version of it already.
WordPress 6.9 will make this the baseline, so there is still time to move off hard-coded AI actions before it does.
