WordPress 6.9's Abilities API: What It Means for Custom Code and AI Agents

WordPress 6.9 "Gene" shipped on 2 December 2025 as the last major release of the year. The visible changes — block-level Notes, a dashboard-wide Command Palette, Accordion and Math blocks — got most of the coverage. The more important change for developers is quieter: the Abilities API.

It is a standardized, machine-readable registry of site functionality. Plugins and custom code can register actions that PHP, REST endpoints, and AI agents can discover and execute the same way. That is the missing layer between "WordPress can do a thing" and "an agent can safely call that thing."

If you still keep customizations in functions.php or a pile of unsigned database snippets, 6.9 is a good moment to tidy the workflow before WordPress leans harder into automation.

What the Abilities API actually is

Until 6.9, site capabilities lived in informal places: hook names only humans knew, REST routes documented in a README, admin-ajax handlers with no schema. An AI tool that wanted to "disable comments on this post type" had to guess which filter to write, or dump PHP into a snippet and hope it ran.

The Abilities API flips that. You register an ability with a name, input schema, permission check, and callback. Anything that can read the registry — a REST client, a WP-CLI command, or an in-admin agent — can list what the site can do and invoke it with validated arguments.

That is closer to how Cursor works against a codebase: the agent sees structured tools, not a blob of undocumented PHP.

Why snippet libraries suddenly matter more

Custom WordPress code is about to be consumed by more than the request that loads it. A snippet that registers a pricing rule, a webhook receiver, or a content filter is no longer just "code that runs on init." It is a candidate ability.

That raises the bar for how you store and review that code:

• Discoverability. If the only copy of a hook lives in a child theme from 2022, no agent and no teammate will find it.
• Permissions. Abilities are supposed to declare who can run them. A snippet that mutates orders without a capability check becomes a much larger problem once something other than a human can trigger it.
• Isolation. A syntax error in a globally loaded snippet still takes down more than the one ability you meant to expose.

This is the same argument we made in how to safely manage WordPress code snippets — 6.9 just made the blast radius more obvious.

What to do with existing snippets

You do not need to rewrite every snippet as an ability on day one. You do need an inventory.

Start by listing every PHP snippet that performs an action another system might want: create a coupon, flush a cache, toggle maintenance mode, sync a product field. Those are the first candidates for an ability wrapper.

Leave presentational CSS and one-off wp_head scripts alone. They are not abilities; they are still snippets, and they still need conditional loading so they do not run on every request.

For anything that *is* an action, wrap the callback behind a capability check and keep the implementation in a file-based snippet — not in the options table. File storage is what Git, OPcache, and HMAC signing all expect.

Where an in-admin agent fits

Core gave WordPress a registry. It did not give you an agent that writes, sandboxes, and deploys the PHP behind those abilities.

That is the gap the Snippet Engineer is built for. You describe the outcome — "register an ability that applies a 15% WooCommerce discount for logged-in users over $100" — and the agent writes the snippet, probes it in a sandbox for fatals, scores the security risk, and waits for approval before publish.

@-mentions let you point the agent at an existing snippet, hook, or project workspace so it extends registered behavior instead of duplicating it. That matters more once abilities become a public contract: two snippets implementing the same action is how you get double discounts and angry clients.

What 6.9 does not solve

The Abilities API is infrastructure, not governance. It will not:

• Stop a fatal in a snippet from white-screening the site
• Tell you a snippet used eval or an unsanitized $_GET
• Sync the same ability definition across a dozen client installs
• Keep a commit history when two developers edit the same callback

Those still belong to a snippet manager with security auditing, GitHub sync, and error isolation. Core opened the door for agents. It did not replace the workflow around the code those agents produce.

A practical 6.9 checklist

• Audit snippets that mutate data. Those should grow an ability registration in 2026, not stay as anonymous add_action calls.
• Move remaining functions.php customizations into a snippet library before the next major. functions.php alternatives covers the tradeoffs.
• Turn on sandbox-before-publish for any AI-generated PHP. WordPress 6.9 makes it easier to *call* code. It does not make generated code safer by default.
• Document hook names and ability IDs in the snippet description. Future you — and any agent — will search for those strings.

WordPress 6.9 is the start of Phase 3 collaboration and the first serious AI substrate in core. The sites that benefit are the ones whose custom code is already inventoried, signed, and reviewable — not the ones still pasting into a theme file.