A client came to me excited about using AI to manage their WordPress content. The dream was a “smart” platform where an AI assistant could draft, revise, and publish posts on its own. Sounds great on paper. But their existing API was a mess of generic CRUD operations, and it kept confusing the AI into unpredictable, sometimes risky behavior. When you hand an AI direct access to your site’s data, you cannot afford that kind of ambiguity.
My first instinct was to map the AI straight to the existing REST API endpoints, maybe with a few wrapper functions around them. That showed its limits fast. You cannot just tell an AI “update a post” and expect it to know which fields it can touch, or what kind of post. Does “delete” mean moving to trash or removing permanently? WordPress has its quirks, and this was a security and logic problem waiting to happen.
Granular WordPress abilities for AI
The core problem comes down to how WordPress abilities, meaning the actions an AI can perform, are defined. The recent Core-AI contributor check-in (full discussion here) raised this exact issue. Lump everything into a single “CRUD” ability for a post type and you are asking for trouble. An AI needs precision.
The recommendation, and the approach we now take, is to break operations into separate abilities. Instead of one bbioon_manage_post ability, you define bbioon_create_post, bbioon_read_post, bbioon_update_post, and bbioon_delete_post. The payoff is clearer annotations. Marking “delete” as destructive tells the AI this is not a casual click. Create and update can often share one ability with an ID parameter to tell them apart, but read and delete each need their own.
Then there is the post type question. Do you build one mega-ability that handles any post type through a parameter, or discrete abilities for each? The group leaned toward discrete abilities: bbioon_create_page, bbioon_create_product, and so on. That keeps AI models from tripping over WordPress’s overloaded terminology, like a “post” of type “post.” It stays explicit, which cuts down on misreadings and surprise side effects.
Permissions are another sticking point. WordPress has granular, context-aware permission levels, and your abilities have to respect them. An “ability vetting check” that pre-filters what an AI can even see, based on the user’s role, is not optional. You do not want an AI trying to delete a page when the underlying user role can only edit posts.
Organization matters for scaling too. Namespaces that show ownership and categories that group related functions help AI models find their way around a growing list of abilities. Picture an AI first asking for “content management” abilities, then narrowing to “post creation.” That is how you build a system people can actually follow. Here is a small example that registers a category for abilities:
<?php
add_action( 'bbioon_register_ability_categories', 'bbioon_register_content_category' );
function bbioon_register_content_category() {
bbioon_register_ability_category(
'content',
__( 'Content Management', 'bbioontheme' ),
__( 'Abilities related to creating, reading, updating, and deleting posts, pages, and custom post types.', 'bbioontheme' )
);
}
// And then, when registering an actual ability:
add_action( 'bbioon_register_abilities', 'bbioon_register_create_post_ability' );
function bbioon_register_create_post_ability() {
bbioon_register_ability(
'bbioon_create_post',
__( 'Create a new WordPress post.', 'bbioontheme' ),
'content', // Assign to the 'content' category
[
'title' => [ 'type' => 'string', 'description' => 'The title of the post.' ],
'content' => [ 'type' => 'string', 'description' => 'The HTML content of the post.' ],
'status' => [ 'type' => 'string', 'enum' => ['publish', 'draft'], 'description' => 'The status of the post.' ]
],
'bbioon_create_post_callback',
[ 'destructive' => false ]
);
}
function bbioon_create_post_callback( $args ) {
// Logic to create a post
return wp_insert_post( [
'post_title' => $args['title'],
'post_content' => $args['content'],
'post_status' => $args['status'],
'post_type' => 'post'
] );
}
?>So what is the real takeaway?
Building solid AI integration in WordPress is not about slapping a generic API on the site and hoping for the best. It takes deliberate, granular design: understanding how WordPress actually works, breaking complex operations into small ones, and giving the AI clear, unambiguous instructions. Do that and the AI can help without putting your site’s integrity or security at risk.
This stuff gets complicated fast. If you are tired of debugging someone else’s mess and just want your site to work, drop my team a line. We have probably seen it before.
