WordPress 7.0 is close, and if you follow WordPress AI Client development the open question is whether it ships in core or stays in the plugin repository. I have watched plenty of “game-changing” features land in core and get refactored three releases later, so I am reading this one carefully. This is not a handful of new blocks. It is a foundational API that will decide how every plugin on the repo talks to Large Language Models (LLMs).
Credential management and the “Connectors” vision
The recent AI Contributor meeting shifted toward a unified “Connectors” screen. The original scope was narrower: how the WordPress AI Client stores API keys. Leadership, Matt Mullenweg included, is pushing for something broader. Rather than separate settings pages for Google Maps, Mailchimp and OpenAI scattered around wp-admin, external service credentials would live in one place.
Architecturally that is the right call. Everyone who has shipped an integration has fought with transients or option rows holding one API key each, and a single interface would tidy up both the database and the UI. The catch is complexity. With Beta 1 approaching, building a secure and extensible credential store is a lot to ask. Rush it and you inherit the technical debt; wait, and the WordPress AI Client slips to 7.1.
Abilities move to nested namespaces
The team reached consensus on “Abilities,” which are the tools the AI can call to get work done. They will support nested namespaces, so core/settings/get rather than a flat get_settings. Anyone who has worked with the WordPress REST API will recognize the pattern. It keeps things organized, and it lets the ecosystem grow to thousands of abilities without name collisions.
In practice that means dropping function-like strings for a structured hierarchy. Existing single-level abilities will most likely need updating to match the new convention.
// The "Naive" flat approach (Old)
bbioon_register_ability( 'get_post_meta', $callback );
// The "Senior" nested approach (New standard)
bbioon_register_ability( 'core/post/get-meta', [
'callback' => $callback,
'description' => 'Retrieves metadata for a specific post ID.',
'args' => [
'post_id' => [ 'type' => 'integer', 'required' => true ],
],
] );I wrote about why standardizing these APIs matters for performance in my post on WP AI Client Standardizing Generative AI.
Experiments and the MCP protocol
The core merge debate is still running, but the “AI Experiments” plugin is not waiting. Version 0.3.1 shipped with fixes for image generation. The part I care about most is the Model Context Protocol (MCP). Standardizing how context reaches an LLM is the only real defence against the hallucination problems that show up in complicated WordPress installs, so active community PRs for MCP support matter more than the merge timeline does.
The official merge proposal on Make WordPress and the GitHub release notes have the technical detail.
If the WordPress AI Client is eating your dev hours, hand the work to me. I have been wrestling with WordPress since the 4.x days.
Where this leaves plugin developers
The WordPress AI Client has turned into real developer infrastructure rather than a side experiment. Whether it lands in 7.0 or 7.1 matters less than finally having one standard way to handle AI in WordPress. If you maintain a plugin, audit your settings now and work out which of your features could be exposed as “Abilities.”
