Fourteen years of WordPress releases have made me careful with the word “revolutionary.” Some features shipped clean. Others arrived held together with duct tape and hope. The WordPress AI Client proposal for 7.0 reads like the first kind, an architecture that respects how we actually build for clients. At the contributor meeting on February 4, 2026, the team set out the plan for merging the infrastructure into the 7.0 Beta 1 milestone.
Why the WordPress AI Client is going provider agnostic
Vendor lock-in is the trap in any AI integration. Baking OpenAI support straight into core is the tempting version, and it is the version you regret once today’s best model turns into a legacy bottleneck. So the group decided to strip embedded providers out of the PHP AI Client. OpenAI, Google and Anthropic each get their own plugin repository on WordPress.org instead.
Decoupling helps performance and maintainability at the same time. Core keeps the API interface and the prompt builder, which is a small surface to look after, and the model-specific quirks stay in plugins that ship on their own schedule. Anyone who has had to refactor a project because a third-party API changed its schema overnight will see the point.
I went through the earlier architectural decisions in my analysis of navigating the road to Core 7.0.
The kill switch debate: constants or filters
Control was the other big thread. Not every client wants AI processing their data, and some hosting environments block those outbound requests anyway, so there has to be a dependable way to turn the whole thing off. A filter was the starting point. Seasoned developers pointed out the hole in that: any other plugin can filter it right back on.
So the team is adding a constant-based mechanism instead. On enterprise WordPress a constant is a hard site-level decision, the kind a theme or a rogue plugin has no business reversing. In practice it looks like this:
<?php
/**
* The Naive Approach: Using a filter that can be hijacked.
*/
add_filter( 'wp_ai_enabled', '__return_false', 999 );
/**
* The Senior Approach: Explicit site-level control via constant.
* This ensures the WordPress AI Client never initializes.
*/
if ( ! defined( 'WP_AI_ENABLED' ) ) {
define( 'WP_AI_ENABLED', false );
}
MCP adapters and the Abilities API
The meeting also covered the Model Context Protocol (MCP) and the Abilities API. The direction there is less about WordPress using AI and more about WordPress becoming discoverable by it. A generated PHP schema layer, derived from the MCP JSON schema, is the piece that makes that safe. External agents such as Claude Code or Cursor get a described interface to WordPress data structures instead of guessing at them.
The Abilities API is also growing support for deeper nesting of namespaces. That sounds like housekeeping, and it is, but it is the housekeeping that stops two plugins from claiming the same name and taking the site down with a fatal error. The official core proposal has the detail.
If tracking this stuff is eating hours you would rather spend on billable work, I can take it on. I have been working with WordPress since the 4.x days.
What to do before Beta 1
February 19 is the Beta 1 milestone, and it is close. Right now the team is clearing Composer dependency problems and reworking the build so it mirrors the way Gutenberg syncs into core. The practical advice for developers: install the AI Experiments plugin and start testing against it. The WordPress AI Client is infrastructure rather than a feature, and it will shape the platform for the next five years. Better to find out your custom hooks are broken now than on release day.
