Part 5 of a series on the future of the web
The previous posts described a web in transition. AI intermediaries changing the consumption model. Agents emerging as actors that pursue goals. Site delegates representing entities in agent-to-agent interactions. Modalities collapsing so the same content can be presented as text, voice, video, or spatial environments.
All of that points to a question: what does this mean for the platform that powers 43% of the web?
WordPress as a Framework
There’s a framing I’ve used for years: WordPress isn’t just a “website tool”. It’s a framework for functionality and data.
Think about what WordPress actually provides. Structured content with posts, pages, products, and custom types. User roles and permissions. Audit trails and revision history. Media management. Extensibility through plugins and themes. APIs for programmatic access.
The website is one output of that system. It’s not the only output.
WordPress already has multiple output channels. The front-end website rendered through themes and blocks. The REST API for programmatic access by apps and integrations. Social publishing to push content to other platforms. Email for newsletters and notifications. Each of these is a different way to present or distribute the same underlying content.
The site delegate (and to a less flashy extent the markdown exposure of content) is the next output channel. Another way for the content and capabilities managed in WordPress to be accessed and presented. The data stays in WordPress. The permissions stay in WordPress. The audit trail stays in WordPress.
The delegate is just a new interface to that same system.
What Already Exists
This isn’t a future roadmap. The foundation is being built now.
WordPress.com has MCP support built in. The Abilities API shipped in WordPress 6.9. The MCP Adapter connects WordPress capabilities to the Model Context Protocol so AI agents can discover and invoke them. Multiple implementations exist across the ecosystem.
A large portion of the State of the Word in 2025 covered this work, read: https://j.cv/sotw-2025/
The pattern is the same one WordPress has followed before. Create an open standard, high level API, or useful primitive. Build a reference implementation. Let the ecosystem extend it. Don’t lock anyone in.
What this means practically: a WordPress site can already expose its content and capabilities to AI agents through open protocols. I absolutely do that on my blog. Here’s my public MCP server. A .md version of this post. Dozens of abilities. There’s an AI chatbot if you click the star in the menu. The list goes on…
An agent can already discover what my, and many other WordPress website’s have to offer, query its content, and invoke actions. The infrastructure exists.
What’s still developing is that configuration layer. How does a site owner shape what gets exposed? How do they set constraints on what agents can do? How do they define how their entity should be represented? That’s the next phase.
The Delegate as Admin Feature
Think about how WordPress configuration works today.
The admin panel is where a business configures itself. You set your site title and tagline. You define your menu structure. You configure your ecom settings. You set up your contact forms. The admin is the interface for defining what your site is and how it behaves.
Delegate configuration fits naturally into this model. To begin, it’s just another settings area. What do you want an agent to be able to do on your site? What should it never do? What content should be exposed, and what should remain private? What actions are available, booking, purchasing, contacting, and under what conditions? How should your entity be represented, what tone, what priorities, what constraints?
In fact, work has already started on this in the form of Content Guidelines:
For a small business, the defaults should just work. You have a WordPress site, the delegate exposes your content and capabilities sensibly without requiring configuration. You get representation in the agentic web without needing to understand the underlying protocols.
For businesses with specific needs, there’s room to customize. Shape the personality to match your brand. Define negotiation rules. Set constraints on automated actions. The same pattern WordPress has always followed: sensible defaults, progressive disclosure of complexity.
And at some point, even that interface becomes consumed by an AI interaction. Instead of a user configuring a collection of fields, the website itself will interview the entity to understand how it should present as an agent to the public.
I’m pretty bullish on two things in this regard; 1. Voice-based interactions with software, specifically interview-style, where software can easily collect information from an entity in a deeply personal and efficient way, and 2. the majority of these types of agent configurations being stored in traditional plaintext. We’re already seeing a move by the industry to do this with Agent Skills.
Democratizing Representation
This is the throughline.
Twenty years ago, WordPress made it possible for anyone to publish to the web. You didn’t need a developer. You didn’t need to understand servers, or crazy have devops skills. You had something to say, and WordPress gave you a way to say it (in under 5 minutes).
Publishing was democratized.
Now the same thing needs to happen for digital representation. If the web is becoming a network of agents interacting with other agents, everyone needs to be able to participate, and continue to succeed economically. Not just enterprises with AI teams. The local plumber. The independent journalist. The small Woo store. The individual with a portfolio site.
Without accessible tooling, site delegates become another advantage for those who can afford to build custom solutions. The agentic web becomes a place where large players have sophisticated representation and everyone else is just data to be scraped. Or perhaps that agentic web doesn’t even play out. And we end up closing the chapter on the open web, and moving closer and closer towards a small collection of large walled gardens.
WordPress can prevent that. By making delegate functionality a core capability, available to every site, the long tail gets access to the same model as enterprises. The same protocols, the same interoperability, the same ability to shape representation. Democratized publishing becomes democratized representation.
The Long Tail and the Collective
There’s another dimension to this. Remember the collective model from Post 2, where publishers band together to negotiate with AI providers and establish attribution and compensation mechanisms.
The challenge for small publishers is coordination. How does a solo blogger join a collective? How do they get discovered by attribution systems? How do they participate in licensing frameworks?
WordPress can be an aggregator. If you’re on WordPress, participating in the collective could be as simple as toggling a setting. Your content becomes part of the pool. Attribution flows through the system. Compensation gets distributed. The individual site owner doesn’t have to manage any of this directly.
This is what WordPress has always done well. Aggregate the long tail. Provide infrastructure that individuals couldn’t build themselves. Create participation paths that don’t require enterprise resources.
A collective needs scale to have leverage with AI providers. WordPress has scale. The alignment is natural.
If you’re interested, you can see some of my earlier work on RSL, as a plugin for WordPress: https://github.com/Jameswlepage/rsl-wp
Content Management Gets More Important
One thing that might seem counterintuitive: in a world of AI-generated presentations and dynamic modalities, content management becomes more important, not less.
The Site Delegate (agent) draws from your content. The quality of representation depends on the quality of what’s being represented. If your content is disorganized, your delegate’s responses will be disorganized. If your product information is incomplete, your delegate can’t answer questions about your products. If your policies aren’t documented, your delegate can’t explain them.
The canonical content, the structured data, the source of truth, that’s what makes everything else possible. The delegate is just the interface. The CMS is still the system of record.
This is true for modality collapse as well. If the same content can be rendered as text, voice, video, or a spatial environment, the underlying content needs to be structured in a way that supports all of those renderings. Good content architecture enables good presentation across modalities. Poor content architecture limits what’s possible. This is especially true in the enterprise sense when there are hundreds of thousands of items of content.
WordPress has always been a content management system. That role doesn’t diminish in an agentic web. It becomes the foundation that everything else builds on.
The Presentation Layer Evolves
At the same time, the presentation layer does change.
WordPress already has the primitives for dynamic presentation. Synced patterns provide structural interfaces that can be reused across a site. Data bindings allow injecting dynamic content into those structures. Blocks provide a vocabulary of components that can be composed in different ways.
The next step is allowing that structure to be rewritten on the fly. Not arbitrarily, but within constraints. Use these specific blocks. Follow these design guidelines. Stay within these content boundaries. But within those guardrails, generate a presentation tailored to the specific user or context.
This is how personalized experiences become possible without requiring a developer for every variation. The patterns define what’s allowed. The data defines what’s available. AI does the composition. The result is a page that’s generated for this user, for this context, drawing on the underlying content but presented in a way that serves their specific needs.
There are a few fun startups exploring this realm. Flint is my (current) favoriate. But all of them are building from scratch. With that comes the benefit of speed, but the lack of distribution. And in fact, I think the system of modern WordPress is really well positioned for this type of on-the-fly content generation.
For human visitors, this means richer, more relevant experiences. For agents, it means presentations optimized for their mode of consumption. The same content, rendered appropriately for whoever or whatever is accessing it.
Open Protocols, Not Lock-In
Throughout this series, I’ve emphasized that the protocols, and way we build need to be open. This is especially important for WordPress.
The value WordPress provides has never been lock-in. It’s been the opposite: an open platform that you control, that you can extend, that you can leave if you want to. Your content is yours. Your site is yours.
The same principle applies to site delegates. MCP is an open protocol (now) under the Linux Foundation. Agent2Agent is being developed as an open standard, and now also under the Linux Foundation. WordPress implements these protocols; it doesn’t own them.
If you outgrow WordPress, or have specialized needs, you can build your own delegate using the same protocols. This was a core requirement of Abilities API. Something that could be adapted out to protocols like MCP. It will still interoperate with the broader ecosystem. The protocols are the shared infrastructure. WordPress is one implementation, optimized for accessibility and ease of use.
The competitive advantage isn’t the protocol. It’s ease of setup, quality of defaults, the ecosystem of extensions, and trust in WordPress as a steward of open web values. The same things that have made WordPress successful for two decades.
The Path Forward
The web is evolving. The consumption model is changing. Agents are emerging as new actors on the graph. The way entities represent themselves is shifting from static pages to dynamic, adaptive presentation.
WordPress can be the default path into this new web for the majority of sites. Not by forcing adoption, but by making it easy. Sensible defaults that work out of the box. Progressive complexity for those who need it. Open protocols that ensure interoperability.
This is the same pattern WordPress has followed since the beginning. Lower the barriers. Democratize access. Let anyone participate in whatever the web is becoming.
The stakes are real. The open web has always depended on broad participation. If the tools for participating in an agentic web are only available to those with significant resources, the web becomes more centralized, more controlled by large players, less open.
WordPress is positioned to prevent that outcome. By building delegate capabilities into core, by aggregating the long tail into collectives, by implementing open protocols that anyone can use, the platform can ensure that the next era of the web remains as open as the last one.
This is the final post in a five-part series on the future of the web. The series covered how the web is changing, the economics of synthesis, agents entering the graph, the new agent-to-agent interface, and what this means for WordPress.