WordPress 7.2 Roadmap: Agent Identity, MCP, and the Abilities API

WordPress's September 18 roadmap to 7.2 treats agent access as a question of identity, delegation and execution. It describes work on auditable agent identities, appropriate permissions, reusable context and MCP compatibility. These are research and development directions, with no guarantee that each will become part of the release.

The roadmap makes an important boundary explicit: the AI work is being pursued through the AI plugin, and adoption and practical value must be demonstrated before features graduate into Core. A planned capability should not become a promise in a client proposal simply because it appears on a release roadmap.

Consider a studio that gives an agent the task of reviewing outdated documentation. The studio should be able to distinguish that agent's activity from an editor's changes. It should also be able to stop the agent's access without interrupting the editor's ordinary work.

That is the practical reason to care about agent identity. A record saying “the administrator changed this page” is less useful when several people and tools share the same credentials. A separate identity makes it easier to understand responsibility, restrict a task and investigate the result. It also gives the owner a clearer way to withdraw a delegation.

The roadmap's emphasis is therefore worth following even before a final implementation is available. It points toward agents becoming accountable participants in an established CMS rather than invisible processes operating behind a human login.

The official MCP Adapter introduction explains how WordPress abilities can be discovered and executed by external tools. Ability definitions carry input and output schemas, an execution callback and a permission callback. The adapter connects those definitions to MCP.

For developers, the useful architectural idea is that the operation belongs to the application. A protocol adapter should expose it while retaining the application's validation and access rules. Changing an assistant or a transport should not require reinventing the underlying business operation.

For an agency, this suggests a focused first project. Expose a small reporting task, verify what the account can read, and compare the output with the same information in the admin. Expand to editing only when the team can explain the validation, review and publication steps. A list of available tools is the beginning of evaluation.

The 7.2 document also discusses experiments involving WebMCP, reusable knowledge and guidelines, expanded abilities and semantic search. Each deserves its own availability check. The existence of an API foundation does not automatically provide a complete autonomous editorial service.

A useful evaluation separates three questions: what ships in the installed WordPress release, what an installed extension adds, and what is still being tested. That distinction protects the delivery plan while giving experimental work a fair hearing.

WordPress's direction is significant because an established ecosystem is working on the application rules that agents need to act responsibly. Better delegation and clear operational contracts can make automation useful across many plugins and projects. The next milestone to watch is a verifiable implementation with understandable identities, permissions and reviewable outcomes.