A client last month was set on “AI-driven workflows.” They wanted their WooCommerce store to write alt text and product descriptions the moment an image was uploaded. So I did the obvious thing: hooked into wp_handle_upload, fired a request at the OpenAI API, and wrote the response back into the metadata. That version hung the admin screen for five seconds every time while it waited, and if the connection dropped mid-request the upload failed outright. The problem was the shape of it. I had wrapped a synchronous call around work that does not finish on a predictable schedule.
That sent me looking for what the WordPress core team is doing about this, and I found the announcement for the AI Experiments Plugin v0.1.0. It is a canonical plugin, built to test how WordPress will eventually handle WordPress AI integration at a core level rather than to wrap ChatGPT for you. Two pieces of it speak directly to the job I had just botched: “Abilities” and the “WP AI Client.”
What the AI Experiments plugin is trying to standardize
Standardization, mostly. Every developer is currently inventing their own way to talk to an LLM. One uses a custom REST endpoint, the next queues it through Action Scheduler in the background, and none of them agree. The plugin’s answer is a Model Context Protocol (MCP), so WordPress hands data to a model the same way every time. That matters for a boring reason: a custom integration you build this month can be dead weight in six if the core team settles on a different standard.
My mistake was owning the whole AI lifecycle in my own code. The alternative is registering “Abilities” rather than writing another custom API handler. An Ability is how you tell the model that a specific tool exists inside the WordPress context and can be called. The official core announcement lays out where this is heading.
/**
* A conceptual example of how we might register a 'tool'
* following the patterns suggested in the AI Experiments plugin.
*/
function bbioon_register_product_analysis_ability() {
if ( ! function_exists( 'register_ai_ability' ) ) {
return;
}
register_ai_ability( 'bbioon/analyze-product-image', [
'description' => __( 'Analyzes product images to generate SEO-friendly descriptions.', 'bbioon' ),
'parameters' => [
'image_id' => [ 'type' => 'integer', 'required' => true ],
],
'callback' => 'bbioon_handle_image_analysis',
] );
}
add_action( 'init', 'bbioon_register_product_analysis_ability' );
Using the pieces before they reach core
The plugin exists to hand you a consistent set of building blocks. Use them at 0.1.0 and your code already speaks the right dialect when those features migrate into WordPress core, which is the cheap way to avoid vendor lock-in and keep the code maintainable. The standardized client also handles the WordPress-specific parts of the workflow, so you are not writing your own defenses against race conditions and timeouts.
This gets complicated fast. If you would rather not spend your week debugging someone else’s integration, drop my team a line. We have probably seen your version of it before.
Are you waiting for core to catch up, or are you already trying these new “Abilities” on a live project?
