WordPress 7.0 AI Client: What You Need to Know

A native AI client means tighter integration, better performance, and a workflow that actually makes sense inside the tools you already use every day.

There’s quite a bit to unpack here - from how the AI client works with content generation to what it means for your existing setup. This post walks you through the most important things you’ll need to know before you upgrade, so you can make well-educated decisions instead of just reactive ones.

What the WordPress 7.0 AI Client Actually Is

At its core, the AI Client is a standardized layer built directly into WordPress - it gives the platform a single, steady way to connect to external AI providers - without needing a plugin to manage the bridge.

Before this, if you wanted AI features on your WordPress site, you had to use third-party plugins and each plugin had its own way of taking care of API keys, its own settings panel and its own idea of how AI should work. That made things messy fast and it meant no two sites handled AI the same way.

The AI Client changes that by putting the connection layer inside WordPress core itself. Developers can now build AI-powered features that tap into one standardized interface and site owners get a steady experience once they install it.

Kind of like the REST API. When the REST API landed in WordPress core, it gave developers a reliable foundation to build on instead of everyone inventing their own services. The AI Client does something similar for AI integration - it sets the ground rules so the whole ecosystem can move in the same direction.

For site owners, the main benefit is easier setup. You connect an AI provider once at the WordPress level. That connection can become available across all compatible features and plugins. You’re not re-entering API keys in five different places or wondering which plugin is doing what.

For developers, the benefit is even bigger. Writing AI features used to mean picking a provider and hardcoding your integration around it. Now you can write to the WordPress AI Client interface and let the site owner choose which provider to use on their end. That separation makes plugins more flexible and easier to maintain.

It also helps with consistency. When every AI-powered feature goes through the same core layer, it’s easier to log requests, manage errors and manage API usage in one location. That centralized control is something plugin-based solutions have always struggled to give you.

The AI Client changes the architecture of how WordPress works with AI at a basic level. The platform is no longer a blank slate that depends on plugins to wire things together - it now has a native understanding of what AI connectivity looks like and how it should work across the board.

OpenAI, Google AI, and Anthropic - The Three Default Providers

WordPress 7.0 ships with three provider plugins right out of the box: OpenAI, Google AI, and Anthropic, and each one comes as a separate plugin, so you only activate what you actually need. That keeps things clean and avoids loading dependencies for services you’re not using.

All three default providers share the same PHP baseline. You’ll need PHP 7.4 or higher to run any of them, which is a pretty basic bar for most hosting environments at this point.

Provider	Ships by Default	PHP Minimum
OpenAI	Yes	PHP 7.4+
Google AI	Yes	PHP 7.4+
Anthropic	Yes	PHP 7.4+
OpenRouter / Ollama	No	PHP 8.0+

Worth noting: OpenRouter and Ollama are not default providers. They are out there as extra options. But they need PHP 8.0 or higher to run. If your server is still on PHP 7.4, those two are not available until you upgrade.

The separation between default and non-default providers is intentional. The three default providers connect to well-established external AI services with stable APIs. OpenRouter and Ollama serve more use cases - like self-hosted models through Ollama - which explains the higher PHP floor.

From a setup standpoint, the experience across the three defaults is steady. You install the plugin for your preferred provider, add your API key, and the AI Client can start to use it. There’s no difference in how you configure OpenAI versus Google AI versus Anthropic at the plugin level.

The fact that multiple providers are supported matters for flexibility. A plugin developer building on the AI Client doesn’t need to hard-code support for one service. The Abilities API - which the next section covers in detail - is what makes that provider-agnostic strategy a reality.

The Abilities API - From PHP Roots to JavaScript in 7.0

WordPress 6.9 laid the groundwork with the Abilities API on the PHP side - it gave developers a structured way to define what AI can and can’t do within a WordPress environment. WordPress 7.0 takes that foundation and extends it into JavaScript with two new packages.

Those packages are @wordpress/abilities and @wordpress/core-abilities. Together they bring the same permission logic that lives in PHP into the JavaScript layer of the block editor and beyond.

Without a unified layer, you end up with a split system where the server knows one set of rules and the browser-side code knows another. That gap is where things go wrong - an AI action might get blocked on the backend but nothing in the UI reflects that, or a button seems active when the underlying permission has already been denied. The JavaScript packages close that gap.

The result is both sides of the application speaking the same language about permissions. The PHP layer defines the rules and the JS layer reads and respects them in kind.

What Each Package Does

@wordpress/abilities is the lower-level package and handles the core logic for checking and registering abilities. @wordpress/core-abilities sits on top of that and maps those checks to WordPress concepts like user roles, post permissions, and site configuration.

Package	Layer	Responsibility
@wordpress/abilities	JavaScript	Core logic for registering and checking abilities
@wordpress/core-abilities	JavaScript	Maps abilities to WordPress-specific contexts
Abilities API (PHP)	Server	Defines the source-of-truth permission rules

This structure means a developer can write ability checks once and have them work across the editor UI and the server. That consistency matters more as AI actions get more complex and widespread.

It also means plugin developers have a stable API to hook into instead of trying to patch around permission checks in ad hoc ways. That stability is worth mentioning as the next layer of the AI client - the tools and agentic loops - starts to increasingly work inside a WordPress site alongside features like auto-writing blog posts with AI.

Agentic Loops and the 200+ Tools Powering Real AI Actions

There’s a difference between an AI that answers a question and an AI that actually does something. The WordPress 7.0 AI Client is built around the second idea. An agentic loop is when an AI takes an action, checks the result, and then decides what to do next - all without waiting for you to prompt it again.

Consider what that means inside a WordPress install - it can call a tool, read the output, and chain that into another action. That loop can run until the job is finished or until something tells it to stop.

PressArk, one of the first places to build on the WordPress 7.0 AI Client, has registered over 200 AI-callable tools. That number gives you a sense of scale. These tools let an AI do things like read post data, update metadata, query users, and use blocks - all programmatically.

What That Level of Access Means

More tools mean more capability. But they also mean more responsibility in how those tools are scoped. The Abilities API from the previous section factors in here - it’s what prevents a tool from running if the current context doesn’t have permission to use it. If you don’t have that boundary layer, an agentic loop with write access could do unintended things fast.

That’s worth sitting with for a second. An AI that can read, write, and chain actions is helpful - but only if the tools it can reach are the right ones for the job. Registering 200 tools doesn’t mean every tool runs every time. The loop only calls what it needs and what it’s allowed to call.

Tool Category	Example Actions	Requires Permission Check
Content	Read posts, update blocks, set metadata	Yes
Users	Query user roles, fetch profile data	Yes
Site Settings	Read options, modify configurations	Yes
Media	Retrieve attachments, update alt text	Yes

The loop architecture also changes how developers need to think about tool design. A tool built for a single response context behaves differently when an AI can call it five times in sequence. The ecosystem is still working out how to design for that repeated use.

What WordPress 7.1 Changes for Third-Party AI Providers

WordPress 7.0 brought the AI Client to the core. But the next release is where the ecosystem opens up. WordPress 7.1 is targeting August 19, 2026, timed to meet WordCamp US, and one of its headline changes is opening the Connectors page to third-party AI providers.

Right now, the Connectors page is a first-party feature. You can connect to supported providers. But the list is controlled by WordPress core. Version 7.1 plans to change that by letting external providers register themselves through a defined integration path.

That’s a big deal for developers and agencies who have already built workflows around niche or proprietary AI models. A legal tech firm using a fine-tuned contract analysis model, just to give you an example, would be able to surface that provider directly inside WordPress instead of routing around it.

Plugin builders stand to gain quite a bit here as well. Instead of shipping a separate settings panel to manage an AI connection, a plugin could plug into the Connectors page natively. That means a cleaner experience for end users and less duplicated infrastructure for developers too.

Agencies building white-labeled WordPress products have an interesting choice ahead. An open connector ecosystem means you could theoretically lock a client environment to a provider or give clients a curated list of approved options. That level of control wasn’t on the table before.

More providers in the Connectors page means more variation in how tools, token limits, and replies behave. A site owner who switches providers mid-project could find that an agentic workflow built for one model doesn’t translate cleanly to another.

There’s also a quality baseline to consider. WordPress core will probably need to define what a valid third-party connector looks like to avoid a flood of poorly maintained integrations. How that vetting process works hasn’t been decided yet.

The Connectors page going open is the move that turns WordPress into a genuine integration layer between your site and whatever AI infrastructure you run behind it.