WordPress 7.0 is still some way off, but the roadmap for the WordPress AI Client now reads like an actual architectural plan. I have spent over a decade watching “core experiments” either fizzle out or turn into technical debt, so a schema-driven approach to AI features is a relief. This looks like something that could survive contact with a production environment.
The contributor meeting summary from mid-January 2026 shows a change in how we will work with LLMs inside the dashboard. The goal is no longer just making it work; it is a standardized interface that third-party developers can hook into without breaking the REST API. The WordPress AI Client is also being prepared for a core inclusion proposal, possibly bundling the PHP client as a dependency the way core bundles the Requests library.
Pragmatic releases: AI Experiments v0.2.0
Review velocity is a chronic bottleneck in WordPress development. The AI Experiments plugin v0.2.0 milestone is finally wrapping up, with a release imminent. The team wants a more predictable cadence after that, maybe monthly, to avoid the stagnation that kills open-source momentum. I usually take stability over speed, but in AI tooling, not shipping is its own kind of failure.
If you have been following the WordPress AI client roadmap, this version is groundwork. There are no new magic buttons in it. What it does have is the “Abilities” framework, which lets the AI do things like manage posts or change site settings through standardized schemas.
The “kill switch” and the removal of streaming
The PHP AI client (v0.4.0) is dropping streaming support for now. It sounds like a regression, and in a narrow sense it is. But anyone who has tried to run server-sent events across budget shared hosting knows what streaming costs to support at scale. Buffering in Nginx, race conditions in PHP-FPM, and every one of those turns into a core support ticket.
The planned “kill switch” filter is the other useful piece. It lets enterprise sites disable WordPress AI Client functionality outright. On a high-security site where no data should reach an LLM provider, you can just turn it off.
<?php
/**
* Senior Dev Tip: Use a filter to disable AI features based on
* environment or user capabilities before it hits core.
*/
function bbioon_conditionally_disable_ai_client( $is_enabled ) {
// Disable AI features on staging or for low-level users
if ( defined( 'WP_ENVIRONMENT_TYPE' ) && 'staging' === WP_ENVIRONMENT_TYPE ) {
return false;
}
if ( ! current_user_can( 'manage_options' ) ) {
return false;
}
return $is_enabled;
}
add_filter( 'wp_ai_enabled', 'bbioon_conditionally_disable_ai_client' );
MCP and tool discovery
The meeting also covered the Model Context Protocol (MCP), which may be the biggest technical change here for the WordPress AI Client. With MCP, WordPress can generate PHP classes straight from schemas. The AI then discovers what tools and resources exist on your specific site through a strict protocol instead of guessing at your data.
For how this fits the wider ecosystem, I broke down the WordPress 7.0 AI features separately. The direction is “polymorphic abilities”, generic actions that work across different post types, which is the sort of refactoring a core implementation needs.
If the WordPress AI Client is eating your dev hours, I can take that off your plate. I have been wrestling with WordPress since the 4.x days.
The final takeaway
The WordPress AI Client is maturing. Trading streaming for protocol-based tool calling through MCP, plus a kill switch for stability, are the right calls ahead of 7.0. This is the unglamorous work of turning AI into a stable part of the WordPress stack. Watch the PHP client v0.4.0. That is where the architectural decisions are getting settled.
