WordPress 7.0 AI Integration is quickly becoming the most discussed topic in the Make/Core Slack channels, and if you’ve been following the commits like I have, you’ll know this isn’t just about adding a “Generate Text” button. We’re talking about building a standardized, provider-agnostic infrastructure. The recent AI contributor meeting on January 28, 2026, made one thing clear: the community is pushing hard for a February 19 Beta 1 milestone, and the WP AI Client is the centerpiece of that effort.
I’ve seen plenty of “AI-powered” WordPress plugins over the last two years that are essentially just wrapper functions for a curl request to OpenAI. They’re fragile, they bloat the database with redundant settings, and they offer zero interoperability. The WordPress 7.0 AI Integration roadmap aims to fix this by moving the heavy lifting into core, while keeping specific LLM providers (like Claude or GPT-4) as separate packages.
The WP AI Client: Why Core Needs a Foundation
As @justlevine rightly pointed out during the meeting, shipping a strong technical implementation early is the only way to avoid crushing technical debt later. The proposal by @flixos90 suggests merging the WP AI Client directly into WordPress 7.0. This isn’t just a convenience; it’s about providing a unified API that any plugin can hook into. If you want to understand the architectural shift, you should check out my deep dive into why WordPress 7.0 needs this foundation.
The goal is to provide a provider-agnostic client. This means as a developer, you won’t need to worry if the user is using Anthropic, OpenAI, or a local Llama instance. You just call the core API, and it handles the routing. This is exactly how we standardized the Filesystem API and the HTTP API years ago—it’s the “WordPress Way.”
Real-World Execution: The Abilities API
One of the most impressive parts of the weekly summary was the GatherPress AI Assistant demo by @jmarx75. GatherPress is an open-source project aimed at replacing Meetup-style functionality within WordPress. Their implementation uses the Abilities API to map natural language prompts directly to PHP functions exposed via REST.
For example, a user can type “Create a new developer meetup for next Tuesday at 6 PM,” and the AI calculates the date, fetches the venue ID, and populates the event post type—all through a stateful conversation. This isn’t magic; it’s a well-defined set of “Abilities” that the AI client can discover and execute. You can see the actual implementation in their GitHub PR.
Here’s a conceptual look at how you might register a custom “Ability” that the WordPress 7.0 AI Integration could utilize. Notice how we’re using a standardized schema so the LLM knows exactly what parameters to send back.
<?php
/**
* Example of registering a custom "Ability" for the AI Client.
* This is the kind of logic we're seeing in the 7.0 roadmap.
*/
function bbioon_register_event_lookup_ability() {
if ( ! function_exists( 'register_ai_ability' ) ) {
return;
}
register_ai_ability( 'gatherpress/lookup_venue', array(
'description' => __( 'Lookup a venue ID by name.', 'text-domain' ),
'parameters' => array(
'venue_name' => array(
'type' => 'string',
'description' => __( 'The name of the venue to search for.', 'text-domain' ),
'required' => true,
),
),
'callback' => 'bbioon_handle_venue_lookup',
) );
}
add_action( 'ai_client_init', 'bbioon_register_event_lookup_ability' );
function bbioon_handle_venue_lookup( $params ) {
// Logic to search venues post-type and return an ID
$venue = get_page_by_title( $params['venue_name'], OBJECT, 'venue' );
return $venue ? $venue->ID : null;
}The Debate: WP AI Client vs. MCP Adapter
Furthermore, the group discussed the tradeoffs between the native WP AI Client and the MCP (Model Context Protocol) adapter. While MCP is great for external tools, @justlevine argued that the native client offers better control over context and multi-step workflows. If you’re curious about the MCP side of things, I’ve written previously about the WordPress MCP Adapter and how it bridges the gap for AI agents.
Specifically, for projects like GatherPress that live entirely within the WP-Admin, a native client is a no-brainer. It avoids the latency of external adapters and keeps the data within the site’s own ecosystem, which is a major win for privacy and cost management.
Look, if this WordPress 7.0 AI Integration stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
What’s Next for WordPress 7.0?
Therefore, the next three weeks are critical. The team is pushing for a technical PR to be submitted to wordpress-develop before the February 19 deadline. If they miss this, we might see the merge deferred to 7.1. However, given the momentum from the GatherPress demo and the urgency of the official merge proposal, I suspect we’ll see a massive push to get this into 7.0 Beta 1. Stay tuned to the #core-ai channel—this is where the future of WordPress architecture is being written.
