WordPress Grew an API for Agents. Community Software Has Not Noticed.

WordPress core shipped an API that lets an AI agent operate a site through typed, permission-gated capabilities. We went looking for who had built community software on it. The room is empty — which is the opportunity.

Every community organization that has looked seriously at AI arrives at the same impasse. The useful version of the technology needs access to the group’s actual work — its projects, its members, its documents, its decisions. And the easy way to grant that access is to move all of it into somebody else’s product, where the terms of service can change on a Tuesday and the export button is a courtesy.

So the interesting question is not “which AI should our coalition use.” It is: can an agent work inside infrastructure we own, on data that never leaves it, with permissions we set?

As of a few months ago, on the platform that runs something like two-fifths of the web, the answer is yes. And almost nobody has noticed.

What landed in core

WordPress 6.9 merged the Abilities API into core. The idea is small and the consequences are not. A plugin registers an ability: a named capability with a typed input schema, a typed output schema, a permission callback, and annotations declaring whether it only reads, whether it is destructive, whether it is safe to retry. Core validates the input before your permission check ever runs. Only a strict true from that check grants access.

What makes it more than a tidy internal pattern is what sits on top. An ability is discoverable and runnable by any Model Context Protocol client. Register one, and it becomes a tool an agent can use — with no integration work, no bespoke endpoint, no API surface invented for one vendor’s assistant.

That gives you two front doors onto one layer of business logic. A hosted assistant can reach your site through a commercial MCP bridge. An agent running on hardware in your own building can reach the same abilities through your own relay, with a narrower tool list and a different identity model. Validation, permissions and logic are written once and serve both. For anyone whose entire argument is that communities should own their infrastructure, that is a load-bearing detail.

So we went and counted

Theory is cheap. We inspected two live production sites we operate — both on WordPress 7.0, both with the Abilities API answering — and enumerated every ability actually registered on them.

Between the two sites there are roughly 120 active plugins, including a full community platform with groups, forums, private messaging, documents and member profiles, plus a learning management system carrying nearly 700 lessons. Together they expose zero abilities.

The pattern is not mysterious. The vendors who moved first are the ones whose objects are obvious and whose customers are transactional: a product, an order, a meta description, a redirect. Those map onto an ability in an afternoon. The objects that matter for civic work — a project, its phase, its roster, the criteria that say whether the group has actually finished the step it claims to have finished — are harder to model, and nobody sells them by the seat.

Which is a strange and welcome position to be in. The most valuable surface on the newest extensibility layer in WordPress is unclaimed.

What we are building on it

Our community’s method is a six-phase arc a team works through on a real local problem: Spark, Speculate, Plan, Assess, Rank, Kickoff. Turning that into abilities forced two design decisions we now think are the whole point.

Every phase has machine-checkable exit criteria. Three confirmed members and a problem statement to leave Spark. Three distinct options to leave Speculate. Two assessments from different people on every option to leave Assess. The validation runs against the database, not against anything the model asserts — so an agent cannot be talked into advancing a project that has not done the work, and a blocked advance returns the specific unmet criterion. That is the difference between an assistant that is useful and one that is merely agreeable.

There is no publish ability. An agent can draft a deliverable, revise it, record an assessment, propose an advance. Everything it writes lands as a draft, and a human publishes. This started as a defensive choice — it is the answer to the school board’s question — and turned out to be the pedagogically correct one too. A cohort that lets software publish on its behalf has outsourced the thing it came to learn.

Three things we learned the hard way

A big REST API is not the same as the API you need. The community platform we run exposes 121 REST routes — groups, members, profiles, activity, forums, messages, media, moderation, search. Genuinely comprehensive. It has no route for group metadata. So the phase state, the history, the bridge between a group and its publishing surface: all of that is ours to write and ours to maintain. Count the routes you need, not the routes that exist.

Check whether the object you are about to invent already exists. We specified a new content type for project deliverables, then found an installed plugin already providing group-scoped, foldered, permissioned documents — with ninety-odd of them in active use on the very group we planned to pilot on. We are still building our own, deliberately: we want no hard dependency, and the “everything an agent writes is a draft” guarantee is only defensible if we own the save path. But that is now a decision with reasons attached instead of an accident discovered in week six.

Decide where the community layer lives before you promise anyone a subdomain. This is the one that cost us the most rework. Group and membership data in this ecosystem is network-wide — one namespace for an entire multisite install — while posts and pages are per-site. That seam is workable, and it is what lets each federation have its own publishing surface while sharing a member directory. But it only works inside one install. We had a multisite network with no community layer on it and a single-site install holding the entire community, and no amount of architecture diagramming makes those share a group table. A multisite gives you the subdomain-per-federation model. A single-site install does not, no matter what the roadmap says.

Why this is worth the trouble

Because of what it makes possible at the other end. When the ability layer is open and the agent can run on hardware the member owns, the marginal cost of that member’s own work goes to zero — and stays there. It is not a promotional rate. There is no per-seat meter on a box sitting in your own building, and no hyperscaler can match that offer, because for them the inference is the margin.

That is the whole thesis, expressed as a line item rather than a slogan: build bridges between systems people own, instead of moats around systems they rent. The Abilities API is, unexpectedly, a bridge that core built for us. It seems worth walking across before somebody puts a tollbooth on it.