A client reached out last week, a high-traffic publishing site, and their admin area was a graveyard of “AI-powered” plugins. One handled title suggestions, one did alt text, another wrote content summaries. Each carried its own API key and its own settings page, and all three were fighting over the same hook in the block editor. The site was sluggish and the editors complained about UI conflicts every week. Nothing about any of it was standardized.
My first instinct was to write a custom wrapper and pipe everything through a single OpenAI endpoint. That would have been a mistake. All I would have done is add a fourth black box to their stack. What they needed was not more custom code but a standardized framework, and that is what the WordPress AI team is building toward with their new release.
Standardized AI features: a real framework for WordPress
The AI Experiments plugin (v0.1.0) is a useful release. It gives the community a canonical space to work out how AI should live in core, rather than leaving every author to invent their own way of talking to an LLM. The plugin introduces a Registry and Loader system built on the idea that AI should be a set of “Abilities” any plugin can tap into. I saw the announcement on the WordPress AI blog, and the approach reads like the way WordPress usually handles this sort of thing: an extension point first, features second.
The part I care about most is the abstract base class for experiments. If you want to build a feature, say generating a product description, the connection logic and the API key UI are already handled. You extend the base class and register it. That kind of consistency is what keeps technical debt from piling up three years down the line.
/**
* Example of how we might register a standardized experiment
* using the patterns introduced in v0.1.0.
*/
function bbioon_register_product_advice_experiment() {
if ( ! class_exists( 'WordPress\AI\Experiments\Registry' ) ) {
return;
}
$registry = \WordPress\AI\Experiments\Registry::get_instance();
// Registering our custom logic under the new standard
$registry->register(
'bbioon-product-advice',
[
'title' => __( 'AI Product Advisor', 'bbioon' ),
'description' => __( 'Suggests upsells based on product specs.', 'bbioon' ),
'enabled' => true,
]
);
}
add_action( 'wp_ai_experiments_init', 'bbioon_register_product_advice_experiment' );The first experiment in the release is Title Generation. It is a small feature, but it shows the WP AI Client SDK working. It suggests alternative titles inside the editor through a standard API that can eventually support multiple providers, which beats hardcoding OpenAI calls into functions.php.
What this means if you build AI features
If you are shipping AI features today, do not build them in a vacuum. The 0.1.0 release is the groundwork for image generation, alt text suggestions and an “Abilities Explorer” due in v0.2.0. Following the patterns now means your site will not break when those features land in WordPress core. That is a pragmatic reason to pay attention, not a hype-driven one.
This gets complicated quickly. If you are tired of debugging someone else’s mess and want your site to work against modern standards, drop my team a line. We have probably seen it before.
If you are still writing a custom OpenAI wrapper for every small task, the core-led standards are worth a look before you write the next one.
