WordPress 7.0 is creeping up fast, and if you have been following the AI team, you know the stakes for the Beta 1 deadline on February 19. I have seen plenty of core releases where “experimental” features get stuck in limbo, but the current momentum behind WordPress AI Core integration feels different. This week’s contributor meeting made it clear: the focus has shifted from “what if” to “how do we ship this safely.”
The recently renamed AI Contributor weekly meeting tackled the fallout from the AI Experiments 0.2.0 release. We are looking at a tightening of coordination to ensure the Abilities work actually lands in core without causing a regression nightmare.
The Abilities API: Moving Toward Core Post Management
The most critical piece of the WordPress AI Core puzzle right now is the Abilities API. Jorge Costa provided an update that reviews for the “Settings” portion are nearly complete. This is the foundation that allows AI to actually do things on your site, rather than just chat.
Specifically, the “Core Post Management Abilities” PR is under heavy review. The goal is to allow more granular control, such as per-post-type abilities. In my experience, granularity is the only way to prevent a race condition or a permissions leak when you are letting an LLM interact with the database.
If you missed the previous breakdown of why this matters, check out my take on Integrating the WordPress AI Client for the 7.0 roadmap.
PHP AI Client v0.4.0 and Integration Testing
Jason Adams shared that the PHP AI Client v0.4.0 is officially out. The next steps are focused on introducing integration tests. This is a pragmatist’s move; recent bug reports have shown that we need to catch issues earlier in the cycle. When you’re dealing with provider-agnostic SDKs, a tiny change in an OpenAI or Claude response can break a Transient or a Hook downstream if you aren’t careful.
<?php
/**
* Conceptual example of a Post Management Ability registration
* in the upcoming WordPress AI Core structure.
*/
function bbioon_register_ai_post_ability() {
if ( ! function_exists( 'register_ai_ability' ) ) {
return;
}
register_ai_ability( 'core/post-management', [
'capability' => 'edit_posts',
'callback' => 'bbioon_handle_ai_post_request',
'args' => [
'post_type' => [
'type' => 'string',
'required' => true,
],
],
] );
}
add_action( 'init', 'bbioon_register_ai_post_ability' );
MCP Adapter: Keeping the Architecture Clean
The Model Context Protocol (MCP) work is progressing, but the team reiterated that the MCP Adapter will remain a canonical plugin. It will stay separate from the WordPress AI Core client being proposed for core. Furthermore, review bandwidth is the current bottleneck. This is a common “war story” in open source—brilliant code sitting in a PR because the few people qualified to review it are swamped with the 7.0 Beta 1 milestone.
For a deeper dive into why we are using MCP at all, read my analysis on Why the MCP Adapter Changes Everything.
Refactoring for Performance: TypeScript and Data Views
Looking ahead to v0.3.0 of the AI Experiments plugin, there is a plan to refactor the Abilities Explorer to TypeScript. Consequently, this should offer tighter integration with the new Data Views and Forms. Moving to TypeScript isn’t just a “shiny new tool” move; it’s about type safety in an environment where AI-generated payloads can be unpredictable.
Look, if this WordPress AI Core stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
The 7.0 Roadmap Takeaway
The February 19 deadline for WordPress 7.0 Beta 1 is the real test. We need the merge proposals for the AI client and Abilities to land soon. Otherwise, we risk missing the window. Specifically, keep an eye on the “WP Bench” tool tests—while Ollama Cloud results have been poor compared to hosted providers, the tooling itself is proving its worth for benchmarking these core integrations.
