Proposal: Incubate an Agents API substrate in the AI plugin

[lezama]

The AI plugin has several active or planned directions that point toward agentic behavior: Site Agent, Workflow Automation, frontend chat, skills, and richer ability/tool exposure. Those efforts currently seem spread across separate threads, each focused on a product surface or adjacent infrastructure.

Related context:

• Explore an admin Site Agent for executing WordPress actions #189 - Site Agent for executing WordPress actions
• Feature Request: Unified AI Management Layer for WordPress Core #348 - Unified AI Management Layer
• Frontend chat agent powered by site content #142 - Frontend chat agent powered by site content
• WordPress Core Abilities #40 - WordPress Core Abilities
• Skills in a WordPress admin context #430 - Skills in a WordPress admin context
• Add WebMCP experiment #448 - WebMCP experiment
• Proposal: A Standardized Data & State Layer for Agentic AI #99 - Standardized data/state layer for agentic AI

This proposal is narrower than those threads: define a small agent runtime substrate that the AI plugin can incubate before any long-term Core or package commitment.

Problem

A Site Agent or Workflow Automation feature needs more than provider calls and abilities. It needs shared runtime concepts such as agent identity and registration, execution principal / acting user context, capability ceilings, tool visibility and action policy, approval and audit boundaries, sessions and transcripts, and eventually memory/context and workflow contracts.

Without a shared substrate, each feature risks inventing its own version of these concepts.

Proposal

Incubate a small WordPress\AI\Agents module inside the AI plugin.

The substrate should be provider-neutral: it should not own model/provider execution, provider selection, or prompt transport. Those should remain with the AI Client and related integration layers.

This module should be separate from Site Agent UI, conservative about public API commitments, and designed so it could later be extracted into a WordPress-owned building block if the contracts prove useful.

The AI plugin would be the proving ground, not necessarily the permanent owner.

Possible implementation slice

A first implementation could stay intentionally small:

• Agent value object
• Registry
• registration lifecycle hook
• tests
• short documentation explaining incubation scope

Explicitly out of scope for the first slice:

• chat UI
• provider/model execution
• memory stores
• workflow runtime
• Action Scheduler integration
• public REST controllers
• durable run history

Open questions

1. Is wordpress/ai the right place to incubate this substrate?
2. Should the first surface be internal-only, public-but-experimental, or a mix?
3. Should global function names like wp_register_agent() be avoided until the API is closer to Core-ready?
4. What is the right relationship between this substrate, Abilities API, AI Client, MCP/WebMCP, and the proposed AI Management Layer?
5. If this stabilizes, should it be extracted into a separate WordPress-owned package/repo?

The goal is not to land a large agent framework in one PR. The goal is to create a small shared place where Site Agent, Workflow Automation, and future agentic features can converge safely.

[sethrubenstein]

I've just started playing around with the Agents API in building out some analysis and copy editor agents and I'm really liking whats available out of the box. It certainly helps in not having to architect all the fundamentals around storage, two data sync, etc. I also really like the idea of standardizing agents that interact with WordPress in more elaborate ways, making the entire agent experience easily-ish deployable to other sites.

[chubes4]

Here is the initial implementation, currently in a separate plugin: https://github.com/automattic/agents-api

@sethrubenstein stoked that you've had a good experience so far! It's fun to think of the possibilities that could stem from this. Miguel and I are advocating for it as much as we can.