The short answer
Because core shipped plumbing, not features. WordPress 6.9 added the Abilities API, a standard way for plugins to declare what they can do, and WordPress 7.0 added an AI Client, a shared way to talk to an AI model. Neither of them writes a paragraph or builds a page on its own. There is nothing to find in your dashboard because the point was never a button. It was to stop every plugin inventing its own wiring, so that the tools you install can be operated by the AI apps you already use.
If you have updated recently and gone looking for the AI everyone is writing about, you have probably had a confusing afternoon. The release notes are full of it. The dashboard is not.
That gap is not a bug and it is not marketing. It is a deliberate decision about what belongs in core, and understanding it tells you something useful about which tools are worth buying this year.
What actually shipped, and when?
Three releases matter, and they are worth separating because coverage tends to blur them together.
WordPress 6.9, December 2025: the Abilities API. A standard way for core, plugins and themes to declare the things they can do. Each ability states its inputs, its outputs, who is permitted to run it, and the code behind it. They are also reachable over the REST API, which is what makes them discoverable by other software rather than only by the plugin that wrote them.
WordPress 7.0 Armstrong, May 2026: the AI Client. A shared way for plugins to send a prompt to a model without each one bundling its own code for it. It is provider agnostic, so the model behind it can be Anthropic, Google, OpenAI or something else, and the release added a central screen for managing those connections. It also added a client-side companion so abilities can be triggered from the editor interface.
WordPress 7.1 Mary Lou, August 2026. Continued work on the same foundation, including the first practical read-only abilities in core itself.
The through line is that every one of those is a socket. None is a lamp.
Good to know
Versions and dates here are as of September 2026 and come from WordPress's own release announcements rather than from our testing. We build on Bricks rather than on core AI features, so treat this as an orientation to a moving target and check the current release notes before making a decision that depends on a specific version. The primary sources are the core team's Abilities API post for 6.9 and the WordPress developer blog's introduction to the Abilities API.
What is an ability, in plain English?
A labeled thing your site can do, described well enough that software can find it and use it correctly without a human explaining it first.
Think about what that replaces. For twenty years, the ability to, say, update a product price lived inside a plugin as a function with a name only that plugin knew, reachable through a handler only that plugin documented. Another piece of software could not ask what your site was capable of. There was no list. There was no format for a list.
An ability is that list entry, standardized. It carries four things: what you have to give it, what you get back, who is allowed to run it, and what it does. The first three are the interesting ones, because they are what makes it safe to hand to something that is not a person.
Why does a standard for this matter?
Because the alternative is what the last two years looked like: every AI plugin building its own private bridge into WordPress, each one working only with the model it shipped with, each one asking for permissions in its own way, and none of them able to cooperate.
A shared standard changes the shape of the market. A plugin that declares its abilities properly can be driven by an AI app the site owner already pays for, rather than requiring a subscription to whatever the plugin author wired in. That is better for you and considerably less comfortable for anyone selling AI credits as a markup on someone else's model.
It also makes permissions legible. When every ability declares who may run it, the question of what an AI is allowed to touch on your site has an answer you can inspect, instead of being buried in the plugin's source code.
Where will you actually meet this?
In the plugins you install, which is the whole point of infrastructure. The clearest example in our corner of the ecosystem is Bricks 2.4, which declares its builder actions as abilities: creating and editing pages, adjusting theme styles, working with templates. We counted roughly 145 of them on the Bricks AI screen, though the changelog states no number, so treat that as our count rather than an official one.
Bricks did not build an AI. It described what the builder can do in a format an AI can read, and left the thinking to a client you connect. If you want the detail on that specifically, we wrote Bricks 2.4 AI explained for non-developers and a hands-on test of what it produced.
The pattern repeats. Core describes, plugins describe, and the useful work happens when something on the outside reads those descriptions and acts on them. Which raises the obvious question.
How does this relate to MCP?
They are two halves of one road, and people conflate them constantly.
The Abilities API is the WordPress side. It declares what exists. MCP is the connection standard AI applications use to discover and call actions in other software. Something has to translate between the two, and that translation is what lets an assistant running on your laptop operate a site running on a server.
The practical consequence is that declaring abilities does not put your site online for any AI to use. It publishes a menu inside your own house. A connection still has to be made deliberately, and it is that connection, not the menu, that deserves your attention when you think about access and risk. Our plain-English MCP guide covers the connection side, and how to connect Claude to Bricks walks through making one.
Should you do anything about it?
As a site owner, no. There is no setting to change and no upgrade to chase. This is scaffolding, and scaffolding is supposed to be boring.
As someone choosing tools, yes, and it is a genuinely useful filter. When you evaluate a plugin that advertises AI, the question worth asking is whether it describes its capabilities in the standard way or keeps them private. The first kind can be driven by whatever AI app you prefer and will still work when you change your mind about which model to pay for. The second kind is a bet on one vendor's roadmap.
The same filter applies to who pays for the model. A tool built on the shared plumbing can let you bring your own key and pay the provider directly. A tool built on private plumbing usually cannot, which is why it sells you credits instead. We wrote about what that difference costs in what AI web design actually costs.
Bottom line
WordPress spent three releases building the part nobody can screenshot. The Abilities API gives your site a readable list of what it can do, the AI Client gives plugins a shared way to reach a model, and core deliberately stopped there rather than shipping an assistant nobody asked for.
So the honest answer to why you cannot see it is that there is nothing to see yet, and that this is the good outcome. The alternative was fifteen plugins with fifteen private bridges and a subscription attached to each. What you should expect instead is that the tools you already use quietly become operable by the AI app you already have, which is a much duller sentence and a much better deal.
FAQ
Questions about this topic
Does WordPress have AI built in now?
It has the parts an AI feature is built from, not an AI feature. WordPress 6.9 added the Abilities API, which is how software declares what it can do, and WordPress 7.0 added an AI Client, which is how software talks to a model. Neither writes your posts. Core shipped the wiring and left the appliances to plugins, which is why you can update, go looking for AI, and find nothing.
What is the WordPress Abilities API?
A standard way for core, plugins and themes to declare the things they can do, in a format both people and software can read. Each ability describes its inputs, its outputs, who is allowed to run it, and the code that runs it. Before this, the same functionality lived in scattered custom functions and AJAX handlers that nothing could discover automatically.
What is the difference between the Abilities API and MCP?
The Abilities API is the WordPress side: it declares what your site can do. MCP is the industry standard AI apps use to call those actions from outside. One describes, the other connects. A site can register abilities and never expose them to any AI, and that is a normal thing to want.
Do I need to do anything about this?
Not as a site owner. It is infrastructure, and you meet it through plugins that use it rather than directly. It is worth understanding if you are choosing tools, because a plugin built on this standard can be operated by AI apps you already use, and one built on its own private plumbing cannot.
Is my site now exposed to AI without my knowing?
Registering an ability is not the same as publishing it. Abilities carry their own permission checks, and something still has to connect an AI client to your site before anything outside can call them. As of September 2026 core ships no active AI feature and no connection is made for you. The exposure comes from what you install and connect, which is the same as it has always been.