The Abilities API: What Core Gave Plugin Authors

Every few years WordPress core absorbs a problem that every plugin had been solving separately. Custom fields, then the REST API, then the Interactivity API. The Abilities API is the current instance, and the problem it absorbs is this: a plugin that wants to expose a capability to something outside itself has historically had to invent its own endpoint, its own permission model and its own way of announcing that the capability exists.

What an ability is in core terms

The API arrived in WordPress 7.0 “Armstrong”, released 20 May 2026, alongside an AI Client in core. The announcement describes the AI Client as letting WordPress communicate with generative AI models with connections managed from a single hub in the dashboard, and frames the pairing directly: the AI Client combined with the Abilities API introduces new functionality, workflow automation and creation tools.

The mechanism is a registry. A plugin registers an ability — a named, described, permission-checked unit of functionality — and core holds the list. The 7.0 field guide describes registered abilities as organised into customisable categories, with abilities and categories unregisterable through the PHP API, and documents the client-side half: plugin developers can enqueue @wordpress/core-abilities to automatically fetch and register server-side abilities via the REST API, or enqueue only @wordpress/abilities to work with a plugin’s own client-side abilities. WordPress 7.1, on 19 August 2026, extended it with a filterable execution lifecycle, custom validation and shared discovery.

That last phrase, shared discovery, is the substance. A registry whose contents cannot be enumerated is a list; one that can is an interface.

Why a shared registry beats a private endpoint

The argument is the same one the Interactivity API made about front-end behaviour, and it held there. When every plugin ships its own mechanism, a page running eight plugins pays for eight mechanisms, and nothing composes. The measurable consequences of consolidating that are visible in what the Interactivity API meant for plugin performance.

Applied to capabilities, the argument is about surface area rather than page weight. A bespoke endpoint is a permission model somebody wrote once, usually under deadline, and the history of WordPress security advisories is substantially a history of those. A registered ability inherits a checked, shared path instead. Anyone who has looked closely at what the REST API exposes by default will recognise the pattern: the risk is rarely the documented interface, it is the twelve undocumented ones beside it.

Where this points, on the evidence available

The obvious destination is agent and tool integration — something outside WordPress asking a site what it can do and then asking it to do one of those things. The evidence for that direction is real but should be read carefully rather than enthusiastically.

On 16 September 2026 the WooCommerce developer blog published an account of running a Claude commerce agent on WooCommerce, describing two agent types: a shopper assistant handling product discovery and cart building, and a merchant assistant producing sales insights with staged approvals. The relevant detail for this discussion is how it connects. The merchant side talks to WooCommerce over the REST API; the shopper side uses the Store API with cart tokens; a bridge plugin carries the integration, and when a shopper clicks through to check out, the plugin re-adds each item to the shopper’s own cart with normal stock checks before sending them to checkout. The post presents this as reference code for experimentation rather than production software.

What it does not do yet

That WooCommerce implementation does not register abilities. It is a bridge plugin over existing APIs. This is the honest state of things four months after the Abilities API shipped: the most prominent agent integration in the ecosystem was built without it.

Nothing in core compels a plugin to register anything. Adoption is opt-in, the incentive to adopt is weaker than the incentive to ship, and a registry with three entries offers none of the composability that justifies one. Whether this becomes the standard mechanism or a well-designed API nobody wired up is undecided — and the same question is being answered elsewhere on different terms, which is worth tracking when thinking about what happens when AI clicks instead of you.

The check worth running before you install

For a site owner evaluating a plugin that advertises itself as AI-ready or agent-ready, there is a concrete test that takes less time than reading the marketing page. Ask whether it registers abilities through core’s registry or ships a private endpoint of its own. A registered ability is enumerable, is subject to core’s permission checks and the filterable execution lifecycle added in 7.1, and can be unregistered through the PHP API if you decide you do not want it exposed. A private endpoint offers none of those and is only as safe as the author’s own capability checks.

The second question follows from the first: what can be turned off, and how. An integration you cannot enumerate is one you cannot audit, and on a site that takes payments or holds customer records that is the whole of the argument.