We need to talk about the WP AI Client. For some reason, the community is acting like this is just another API update, but if you look at the proposal for WordPress 7.0, we’re actually talking about a massive shift in core architectural philosophy. I’ve seen enough “revolutionary” features come and go to know that the devil is always in the implementation details—specifically when those details involve bundling third-party dependencies.
The recent AI contributor meeting highlighted some serious friction points regarding the merge. As someone who has spent over a decade refactoring legacy codebases, the concerns about review velocity and technical rigor aren’t just red tape; they are the only things standing between us and a maintainability nightmare. If we ship this too fast, we’re not just shipping a feature; we’re shipping a debt.
The Dependency Dilemma and Core Inclusion
One of the loudest debates centers on whether the WP AI Client should even be in core. Historically, WordPress has been cautious about bundling external libraries. However, the proposal suggests that core inclusion is necessary for accessibility and to avoid long-term maintenance “stacks” that confuse end-users.
I’ve written before about why WordPress 7.0 needs this foundation, but the “Core vs. Plugin” debate is still valid. If we iterate too quickly in core, we risk breaking backward compatibility. If we stay as a plugin, we lose the “standard” status needed to push the ecosystem forward. The current compromise? Reducing the footprint of third-party dependencies to address CI/CD concerns.
Namespaces: LLM Context vs. WordPress Precedent
There is currently a technical tug-of-war over nested namespaces. The WP AI Client team initially pushed for a nested structure like core/settings/get. Why? Because LLMs and agentic workflows thrive on clear, contextual signals. But WordPress precedent is flat. We don’t do nesting.
Look at the difference in how we’d register these abilities. The “WordPress Way” (Flat) versus the “Agentic Way” (Nested) creates a significant fork in how developers will interact with the API.
<?php
/**
* Example of the Ability Naming Dispute
* bb_prefix used to denote potential architectural choices.
*/
// The Proposed Nested Structure (Better for LLMs)
$nested_namespace = 'core/settings/get';
// The Standard WordPress Approach (Flat)
$flat_namespace = 'core-settings-get';
// Why it matters: LLMs can "chunk" the nested version more effectively
// to understand that 'settings' is the domain and 'get' is the action.
function bbioon_register_ai_ability( $name ) {
// Logic to register the ability...
}Abilities Update: The Write-Capable Milestone
The merge of the get settings ability was the “hello world” moment, but the real test is the update settings ability currently in progress. This is the first “write-capable” ability. In the world of AI integration, giving an LLM the “Abilities” to actually modify a database is where things get messy—and dangerous.
We’re also seeing the post ability being pushed to WordPress 7.1. This is a smart move. The REST API hasn’t historically exposed the level of query complexity needed for deep AI analysis, and trying to force that into the 7.0 release cycle (with Beta 1 due February 19th) would be a recipe for a race condition disaster.
Technical Takeaway for Developers
If you aren’t testing the WP AI Client PR yet, you’re going to be playing catch-up in March. Use the provider plugins for Anthropic or OpenAI and leave concrete, experience-based feedback. We need real-world use cases to prove this isn’t just bloat.
Look, if this WP AI Client stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
Final Thoughts
The push for AI literacy within the contributor group is a great sign. We’re moving away from “black box” magic and toward durable knowledge. Whether you’re at WordCamp Asia or following the Make posts, the goal is clear: build a technical foundation that respects the WordPress core while embracing the reality of the evolving landscape. Specifically, watch the namespace discussion—it will dictate the DX (Developer Experience) for the next five years.
