WordPress 7.0 AI Integration has taken over the Make/Core Slack channels. If you have been reading the commits, you already know this goes well past a “Generate Text” button. The work is a standardized, provider-agnostic infrastructure. The AI contributor meeting on January 28, 2026 settled the shape of it: the community wants a February 19 Beta 1 milestone, and the WP AI Client is the centerpiece.
Over the last two years I have looked at a lot of “AI-powered” WordPress plugins that turn out to be a wrapper around a curl request to OpenAI. They break easily, they clutter the database with redundant settings, and none of them talk to each other. The WordPress 7.0 AI Integration roadmap moves that plumbing into core and leaves the individual LLM providers, Claude or GPT-4, as separate packages.
Why core needs the WP AI Client
@justlevine made the point in the meeting that shipping a strong technical implementation early is what keeps the technical debt from piling up later. The proposal from @flixos90 would merge the WP AI Client straight into WordPress 7.0, which gives every plugin one API to hook into rather than each one rolling its own. I went deeper on the architecture in why WordPress 7.0 needs this foundation.
The client is meant to be provider agnostic. You call the core API and it handles the routing, so your code does not care whether the site is set up with Anthropic, OpenAI or a local Llama instance. Core did the same thing years ago with the Filesystem API and the HTTP API. It is the “WordPress Way,” and it holds up.
The Abilities API in practice
The demo that stuck with me from the weekly summary was the GatherPress AI Assistant from @jmarx75. GatherPress is an open-source project aimed at replacing Meetup-style functionality inside WordPress, and their build uses the Abilities API to map natural language prompts onto PHP functions exposed through REST.
A user types “Create a new developer meetup for next Tuesday at 6 PM,” and the assistant works out the date, fetches the venue ID and populates the event post type, all inside one stateful conversation. Underneath it is a defined set of “Abilities” that the AI client can discover and execute. Their GitHub PR has the implementation.
Below is a rough sketch of registering a custom “Ability” that the WordPress 7.0 AI Integration could pick up. The schema is the important part, since it tells the LLM which 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;
}WP AI Client or MCP adapter
The group also weighed the native WP AI Client against the MCP (Model Context Protocol) adapter. MCP does well for external tools, but @justlevine argued the native client gives you better control over context and multi-step workflows. I covered the other side of that in my post on the WordPress MCP Adapter and how it bridges the gap for AI agents.
For something like GatherPress, which lives entirely inside WP-Admin, the native client is the easy call. There is no external adapter adding latency, and the data stays inside the site’s own ecosystem, which matters for privacy and for the bill.
If keeping up with this 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 is next for WordPress 7.0
The next three weeks decide it. The team needs a technical PR in wordpress-develop before February 19, and if that slips the merge probably moves to 7.1. My guess is that it lands. The GatherPress demo gave the effort real momentum, and the official merge proposal is written with the deadline in mind. The #core-ai channel is where to watch it happen.
