For two decades, WordPress has been extensible in one primary way: you write PHP, hook into an action or a filter, and change behavior. That model built an ecosystem of tens of thousands of plugins. But it was designed for developers reading documentation, not for software agents trying to figure out what a site can do on their own.
That is the shift now underway. WordPress is quietly being rewired so that AI systems can discover, understand, and safely invoke what a site is capable of. It is less glamorous than a chatbot in the dashboard, and far more consequential.
Image: Pixabay, free under the Pixabay Content License. Source: pixabay.com/p-2167835.
The problem agents actually have
An AI agent that wants to "publish this post and schedule a newsletter" faces a surprisingly hard problem on a typical WordPress site. It has to know which plugins are installed, which REST routes exist, what parameters each one expects, what permissions are required, and what side effects follow. Most of that knowledge lives in scattered docs, in code, or in the head of whoever built the site.
Historically, tools solved this by scraping, guessing, or hard-coding integrations per plugin. That is brittle. Every plugin update can break the assumption, and every new plugin is a new integration project.
Abilities: a registry of "things this site can do"
The direction WordPress core has taken is to introduce a standard way for plugins and themes to declare their capabilities in machine-readable form: a name, a description, an input schema, an output schema, and a permission check. Think of it as an index of verbs for the site.
The important design choice is that an ability is described once and consumed by many clients. The same declaration can power an admin UI button, a REST endpoint, a command-line tool, and an AI agent. Nobody has to write a separate integration for each.
MCP: the protocol that connects the dots
The Model Context Protocol (MCP) is the open standard that lets AI clients talk to tools in a uniform way. When a WordPress site exposes its abilities through an MCP adapter, an MCP-capable client can list what is available and call it, with the same authentication and capability checks the site already enforces.
We covered an early example of this in our post on Novamira MCP and AI-powered site building. What has changed since is that the pattern is moving from experiments toward infrastructure that core itself acknowledges.
What this means in practice
A few concrete consequences are worth thinking through.
Integrations stop being bespoke. If a form plugin, an SEO plugin, and a commerce plugin all describe their abilities in a standard way, an agent can orchestrate across them without a custom connector for each pair.
Permissions become the real product. The scary question is not "can an agent publish a post," it is "should this agent, acting for this user, be allowed to publish right now." WordPress already has a mature capability system. Reusing it, rather than inventing a parallel one, is what makes this approach credible.
Audit trails matter more. When a human clicks Publish, there is an implicit accountability. When an agent does it, you want a record of who requested it, what was invoked, with which inputs. Expect logging of agent actions to become a standard hosting feature.
What this changes for hosting
At XeroWP we think about this from the infrastructure side. If agents are going to operate sites, the hosting layer has to answer questions it never used to face:
- Identity: how does a site tell a human admin from an agent acting on their behalf?
- Scoping: can you issue a credential that can edit drafts but never touch plugins or users?
- Rate and cost control: an agent in a loop can hammer a site faster than any human. Per-site limits become a safety feature, not just a billing one.
- Reversibility: snapshots before agent-driven changes, with one-click rollback, turn an anxious experiment into a routine one.
None of these are exotic. They are the same disciplines we already apply to deployment pipelines, applied to a new kind of operator.
A measured view
It is tempting to oversell this. Agents still misread intent, hallucinate parameters, and confidently do the wrong thing. A schema constrains inputs, but it cannot guarantee judgment. For the foreseeable future the right posture is human-in-the-loop for anything destructive or public, and autonomy for the boring, reversible, well-bounded tasks.
Still, the direction is clear. The sites that will be easiest to automate are the ones whose capabilities are declared, permissioned, and observable. That is good engineering regardless of whether AI is involved.
What you can do now
- Audit your plugin stack for ones that expose clean REST or ability-style interfaces; prefer those.
- Use application passwords and scoped roles for any automation rather than a shared admin login.
- Snapshot before you automate. Make rollback cheap before you make changes cheap.
- Log agent activity separately so you can answer "what changed and why" a month later.
The plumbing of the next WordPress era is being laid now. It will not look like a robot in your dashboard. It will look like a well-documented set of verbs your site can perform, and a lot of careful thought about who is allowed to say them.
