WordPress 7.0, named Armstrong, was released on 20 May 2026. It is the release that put AI into core, and the reporting on it has been loose enough that a fair number of site owners now believe their dashboard has grown a writing assistant.
It has not. What shipped is plumbing. There is an AI Client that plugins can call, a Connectors screen where API keys live, and the Abilities API, which is the piece most articles get wrong because it landed in 6.9 rather than 7.0. Core ships no AI provider at all, and a fresh 7.0 install with nothing else added will not generate a word of anything.
That distinction is the whole story, so here is what each piece is, what it enables, and the questions I would want answered before any of it goes near a site I look after.
The AI Client is an interface, not a service
The AI Client is a provider-agnostic PHP API. A plugin calls wp_ai_client_prompt(), describes what it wants, and WordPress routes the request to whichever model the site is configured to use. The dev notes describe support for text, images, speech and video where the provider offers them, plus structured JSON responses against a schema you define.
The important word is provider-agnostic. Before this, every plugin that wanted to talk to a model wrote its own integration, its own settings page and its own API key field. Ten such plugins meant ten key fields and ten different ways of handling failure. The AI Client replaces that with one interface, so a plugin author writes the feature once and it works with whatever the site owner has connected.
Core bundles the client library and nothing else. The providers are separate plugins, with three official ones for Anthropic, Google and OpenAI and the door open for others. There is also a documented way for a plugin to check whether text generation is possible on this site before it shows a button, which tells you what kind of feature this is. It assumes most sites will have nothing configured, and expects plugins to degrade quietly when they do.
If you write plugins, this is useful. If you run a website, on its own it does nothing.
Connectors is where the keys live, and where the questions start
Settings, then Connectors, is the new hub. Registered connectors appear as cards with a link off to the provider to create credentials, and you paste a key in. WordPress 7.0 ships with Anthropic, Google and OpenAI as featured connectors.
Three details are worth knowing, none of them hidden. They are stated plainly in the dev note.
First, keys can come from three places, checked in order: an environment variable, a PHP constant, then the database. A key entered through the admin screen goes in the database.
Second, keys in the database are masked in the interface but are not encrypted. Encryption is described as being explored separately, so treat that as the position as things stand rather than the permanent design.
Third, and this is the one I would put in front of any agency running client sites: there is no scoping. Any plugin on that site can use a configured key. You are not granting access to the plugin you installed it for. You are granting it to everything on the site, including whatever gets installed next year by someone who was not in the room today.
That is not a scandal. It is the same trust model WordPress has always had for plugins, which can already read your database and make outbound requests. It is just worth understanding before you paste a billing-attached credential into a site that four people can log into. If your user accounts are looser than you would like, roles and capabilities is the thing to tidy first.
The Abilities API is the quieter, more interesting piece
The Abilities API arrived in WordPress 6.9 in December 2025, and 7.0 added a client-side JavaScript counterpart plus command palette integration. Most coverage folds it into the AI story, which undersells it.
An ability is a named unit of functionality registered with wp_register_ability(), following a namespace/ability-name pattern. It carries a name and description, input and output schemas in JSON Schema, a category, a callback that does the work, and an optional permission callback checked with the same current_user_can() rules as everything else in WordPress. Abilities can be exposed over the REST API and run by request, with that permission check still applied.
Read that again without the word AI in your head. It is a registry of “things this site can do”, each with a defined input, a defined output and a capability check. That is a description of well-behaved plugin architecture. Plenty of plugins expose their functionality through ad-hoc admin-ajax handlers with the security check written from memory, and I have fixed enough of those to be pleased that core now offers a shape with the permission callback built into the registration rather than remembered afterwards.
Whether AI ever touches your site, this is the better way to expose functionality that something else needs to call. It happens to also be the surface an AI agent can discover and use, which is why it is being talked about the way it is. Agent access itself runs through a separate MCP adapter plugin maintained by the core AI team, not through core.
The bit people actually mean by “AI in WordPress”
The features people imagine when they hear the headline, generating a featured image, writing an excerpt, producing alt text, live in a plugin called AI on wordpress.org, published by the project itself. Its listing describes it as experimental and says functionality may change. It requires WordPress 7.0, the block editor and at least one configured connector, which means your own provider account and your own API key.
So the actual chain is: install a provider plugin, add your key on the Connectors screen, install the AI plugin, turn on the specific options you want. Four deliberate steps, all opt-in, none of which happen because you clicked update.
I think that is a good design. Core provides the pipe and leaves the water to you. Nobody gets AI features they did not ask for, no site starts making outbound requests it was not configured to make, and no version of WordPress arrives with a bill attached.
What to ask before any AI feature touches a client site
Three questions, and I would want all three answered before switching anything on for someone else.
Where does the data go? Whatever the feature sends leaves your server and goes to the provider you configured, under that provider’s terms, not WordPress’s. Core is the pipe. If the content being processed includes anything you would not email to a third party, that is your answer. This matters far more for customer data than for blog drafts.
Who pays for the tokens, and what stops the bill? You do, through your own account with the provider. As things stand I am not aware of any spend cap or usage dashboard in core, so the only controls are the ones your provider gives you. If you set this up for a client, set the limit at the provider end on day one, not after the first invoice.
What happens when the terms change? You are taking a dependency on a commercial service that can reprice, deprecate a model or change what it permits, on its own schedule. The provider-agnostic design helps, because swapping providers is meant to be a configuration change rather than a rebuild. It is still the sort of thing that quietly stops working, which is a large part of what a maintenance plan is for.
Common questions
Does updating to WordPress 7.0 turn AI on?
No. Core ships no providers, and the user-facing features live in a separate plugin. With nothing configured, nothing runs and no requests leave your server. Update on staging first as with any major version, but not because of this.
Do I need an API key to use WordPress 7.0?
No. Everything else in the release works normally without one. A key is only needed if you deliberately connect a provider.
Is it safe to put my API key in the WordPress dashboard?
It is stored masked but not encrypted, and any plugin on the site can use it. If that gives you pause, define it as an environment variable or PHP constant instead, which WordPress checks first. On a client site with several administrators, I would use the constant.
Does this replace the AI plugins I already use?
No, and existing plugins are not obliged to move. Over time I would expect authors to adopt the core client, because it means one key on the Connectors screen rather than a key per plugin. That is a slow change, not a switchover.
Can AI agents now edit my site?
Only if you install and configure the parts that allow it. Abilities carry permission callbacks checked against normal user capabilities, and the MCP adapter that exposes them to agents is a separate plugin. Nothing in a default 7.0 install gives an outside agent access.
What I am doing about it
Nothing urgent, on any client site. There is no forced change, no deadline and nothing you miss by leaving it alone, and I would not install an experimental plugin on a site that earns money to keep up with a headline.
Two things I would use it for, and I will be specific rather than enthusiastic. The first is alt text on image-heavy sites. Filling in three hundred missing alt attributes by hand is a job nobody has ever budgeted for, and a first pass I then read and correct is worth real time. It needs the human eye, because a model describes what is in the picture and not what the image is doing on that page. But a corrected draft beats an empty field, and empty fields are an accessibility problem I see constantly.
The second is not an AI use at all. When I build a custom plugin that has to expose functionality to something outside itself, I would now register an ability rather than write another admin-ajax endpoint. Defined input, defined output, permission callback in the registration. That is the part I expect to still be using in five years, whatever happens to the rest of it.
My honest read: interesting infrastructure, sensibly designed, no reason to rush. The time to look at it properly is when a job appears that it solves, and if you think one of yours might, tell me what you have got and I will give you a straight answer.
