I’ve spent the past several months writing about site delegates and the shift from human-to-site interaction to agent-to-agent negotiation. A question that keeps coming up is where these agents actually get built. The answer, increasingly, can be WordPress itself.
WordPress 6.9 shipped the Abilities API. The WP AI Client is proposed for 7.0. The MCP Adapter is production-ready. A Workflows API is on the roadmap. These are layers of a stack that lets WordPress sites become agents themselves, not just platforms that agents connect to from the outside.
The purpose of this post is to showcase many of the AI Building Blocks that I helped design alongside the Core AI team, in the summer of 2025. The goal was that they would become a foundation for developing more advanced functionalities that would drive innovation and engagement in user interactions. This post is proof that that goal is now possible, albeit still early and iterating, like all of AI.
While I don’t expect WordPress to be “the agent builder”, the evolution of the platform to meet these needs aligns well with my thinking on the future of the web. If sites will grow to represent their “owners” agentically, it makes sense that the agent is based within said site to me. On the flip side, we’ll need to make sure that third party agents can interact with both a site (ie to manage) and site delegate (ie to ‘learn about the entity it represents’) as well. To me, there’s no winner takes all. WordPress wins when it becomes that decentralized, central source of truth for an agentic web.
The Building Blocks
The Abilities API shipped in WordPress 6.9. It creates a central registry where plugins, themes, and core expose capabilities in a machine-readable format. Each ability has a unique namespaced identifier, input and output schemas using JSON Schema, a permission callback, and an execution callback. Registration happens on the wp_abilities_api_init hook:
add_action( 'wp_abilities_api_init', function() {
wp_register_ability( 'my-plugin/summarize-post', array(
'label' => 'Summarize Post',
'description' => 'Returns an AI-generated summary of a post',
'category' => 'content',
'input_schema' => array(
'type' => 'object',
'properties' => array(
'post_id' => array( 'type' => 'integer' )
),
'required' => array( 'post_id' )
),
'output_schema' => array( 'type' => 'string' ),
'callback' => 'my_plugin_summarize_post',
'permission_callback' => function() {
return current_user_can( 'edit_posts' );
},
'meta' => array( 'show_in_rest' => true )
));
});
Code language: PHP (php)What makes this useful for agents is the uniformity. Every ability describes what it does, what it accepts, what it returns, and who can execute it. That’s exactly what an LLM needs to decide which tool to call. Today, the basis of how LLMs interact with software is this tool or function calling, which is essentially structured decoding. Abilities map directly to tools, as designed. REST API exposure is automatic when you set meta.show_in_rest to true, making abilities queryable at /wp-json/wp-abilities/v1/.
More on abilities: Creating Abilities API
The WP AI Client is proposed for WordPress 7.0. It’s a provider-agnostic interface to LLMs built on the PHP AI Client SDK. The fluent API:
use WordPress\AI_Client\AI_Client;
$summary = AI_Client::prompt( 'Summarize this content: ' . $post->post_content )
->using_temperature( 0.3 )
->generate_text();
Code language: PHP (php)The site administrator configures which providers they have API keys for in Settings → AI Credentials. Plugin developers don’t (need to) specify a model. The SDK picks one that supports the capabilities needed. Your plugin works regardless of whether the site uses OpenAI, Anthropic, Google, or a local model.
The MCP Adapter bridges these pieces to the Model Context Protocol. It translates WordPress abilities into MCP tools, resources, and prompts. When an external agent connects to your site’s MCP server, it discovers available actions and can invoke them directly. The adapter supports HTTP transport for remote connections and STDIO transport for local development via WP-CLI. Soon, it’ll support the other side to MCP, clients, allowing WordPress itself to connect to MCP servers.
What This Enables
An agent is an LLM in a loop. You provide tools. It reasons about which tool to call. It calls the tool. It takes the output and decides what to do next. The loop continues until the task is complete.
Artur Piszek’s PHP can AI: WordPress.com Agentic Infrastructure shows this pattern running in production at Automattic. We’ve invested thousands of dev-hours into this thinking and work. The core of it is roughly:
do {
$response = $this->complete( $messages );
foreach ( $response as $message ) {
if ( $message instanceof Tool_Call ) {
$result = $this->call_tool( $message );
$messages[] = $result;
}
}
} while ( $max_loops-- > 0 && $this->should_continue( $messages ) );
Code language: PHP (php)With the building blocks in Core, you can create this loop yourself. Register abilities for the actions you want. Use WP AI Client to query an LLM. Pass your abilities as tools. Execute whichever tool the LLM selects. Feed the result back. Continue until done.
The MCP Adapter lets you expose this externally. Install the adapter, create a server on the mcp_adapter_init hook, and external agents can discover your site’s abilities:
add_action( 'mcp_adapter_init', function( $adapter ) {
$adapter->create_server(
'my-agent-server',
'my-namespace',
'mcp',
'My Site Agent',
'Exposes site capabilities to AI agents',
'v1.0.0',
array( \WP\MCP\Transport\HttpTransport::class ),
null, null,
array( 'my-plugin/summarize-post', 'my-plugin/create-draft' )
);
});
Code language: PHP (php)Point Claude Desktop or Cursor at https://yoursite.com/wp-json/my-namespace/mcp and the agent discovers your tools. Then, externally, it simply uses those tools in a loop, interacting with WordPress outside – in.
Abilities are quite self-documenting. You also have an “agent in a box”, no batteries included, if you simply retrieve the list of abilities in an authenticated manner (read; app passwords) from the REST API. Just provide the loop. Build it in python, use some existing SDK, plug it into Caude Code…
Three Patterns
There are three ways to package these pieces together.
Single-shot actions are the simplest. A button in the editor that calls one ability. Generate alt text for an image. Suggest a title. Summarize content. One click, one tool call, done. But that’s no agent.
Deterministic workflows chain multiple abilities in a fixed sequence. When a post is published, generate a summary, create a social image, schedule distribution. The Workflows API arriving in 7.0 provides this. It sits on top of Abilities and defines triggers, conditions, and sequences. You get observability because the flow is predetermined.
Agentic loops let the LLM choose. You provide a set of abilities as tools. The LLM decides which to call based on prompt and context. It might call several in sequence. It might loop back. The reasoning happens in the model, not in your code.
You can mix these. A workflow might include an agentic node where the LLM makes decisions within a bounded scope. A workflow itself can be exposed as a single ability that an agent invokes.
Site Delegates
The difference between an agent helping a site owner and a delegate representing the site to others is configuration, not architecture. Same abilities. Same loop pattern. Different guardrails, different instructions, different authentication, different user capabilities.
A management agent operates in the admin context with user capabilities. Roles and revisions are important here. A site delegate operates publicly with constrained permissions. Public visibility and convergence with adopted standards is key. Both draw from the same registry. Both use the same infrastructure.
The protocols are stabilizing. MCP is now under the Linux Foundation with support from Anthropic, OpenAI, Google, and Microsoft. Agent2Agent is being developed for agent-to-agent communication. (there a lot more – Agent Client Protocol, UTCP, et) As these mature/freeze, sites can ship with default delegates that represent them to the broader agent ecosystem.
Why PHP
PHP critiques exist. The counterargument is proximity to content.
WordPress sites have twenty years of content and business processes encoded into them. The agents need to operate on that content. Running the agent where the content lives means direct database access, existing permission systems, built-in revision history, and no additional infrastructure to manage.
Documentation matters more than language. Coding agents can write PHP if the patterns are documented. Register abilities with a standard schema. Query LLMs through a standard client. Expose tools through a standard protocol. Follow the conventions, and the language becomes incidental.
And again, as Artur illustrates, loops are pretty darn easy to do in PHP, and the eight version of the language is actually quite nice to work with.
What to Build
Start with a single ability. Something your site can do that would be useful to expose. Register it with wp_register_ability(). Give it a clear description, input schema, output schema, and permission callback. Enable REST API exposure.
Build a simple loop. Use WP AI Client to send a prompt with your ability as a tool. Execute the tool call. Return the result.
Install the MCP Adapter. Point Claude at your site’s MCP endpoint. Ask it to do something that requires your ability. Watch it discover the tool and invoke it.
The AI Experiments plugin serves as a reference implementation. The documentation is at developer.wordpress.org/apis/abilities-api/. The repositories are open on GitHub.
This post is a companion to the Future of the Web series. It’s a good followup to the last post: Future of Web, What This Means for WordPress. The theoretical framework of site delegates and agent-to-agent negotiation needs practical implementation. WordPress now has the primitives. What’s needed is adoption, experimentation, and contribution to move these APIs forward faster.