The WordPress agentic web is not a fantasy. Automattic said it out loud. The infrastructure to support it is shipping in WordPress 7.0. The Abilities API is real, MCP is real, and the vision of WordPress as the operating system of the agentic internet is closer than most people realize. However, there is a version of this that goes sideways. Not because the technology fails. Because the people building on top of it keep making the same assumption. That WordPress users need AI to do things they are not capable of doing themselves. That assumption is wrong, it is not new, and if enough developers stay in that lane, we are not building the agentic web. We are building a more expensive version of the same dependency problem we have always had.
This is the third post in a series. Part one was about the hidden WordPress AI plugin token cost inside WordPress AI features. Part two was about WordPress AI plugin lock-in and how it is worse than anything we have seen before. If you have not read those, give them a few minutes of your time. I think they are worth the read. This post is about the assumption underneath both of them, and what we need to do instead.
The WordPress Agentic Web Requires Capable Users, Not Dependent Ones
I have been in WordPress for over 15 years. I co-organized the Las Vegas WordPress Meetup for eight of those years. I have attended more WordCamps than I can count. And the single most consistent thing I have seen in that time is this: when you teach someone how WordPress actually works, something changes in them. They stop seeing a wall and start seeing a door. They stop asking what they cannot do and start asking what is possible.
That moment does not happen when you hand someone a chat widget that generates content for them. It happens when they understand what they are working with. There is a difference between someone who uses the Custom Post Type UI plugin (CPTUI) to register a custom post type because they understand what a CPT is and what problem it solves, and someone who clicks a button that says ‘create a new content type with AI’ without any idea what just happened to their database. The second person is not empowered. They are dependent. And the moment that plugin stops working, they have nothing.
Furthermore, the plugin ecosystem is increasingly building for the second person. Not because those users are stupid. They are not. Because dependency is a better business model than capability. A user who understands WordPress can shop around. A user who has built their entire workflow inside your plugin’s AI assistant cannot leave without starting over.
Nice to Have Is Not the Same as Need to Have
There is a WordPress plugin called WP Content Types that recently shipped an AI feature to help users create custom post types and taxonomies. It is a well-built plugin from people who clearly know what they are doing. But here is the honest truth: the majority of users who would reach for that AI feature do not need AI. They need someone to explain what a custom post type is and why they would want one. Once they understand that CPTUI costs a fraction of what an AI-powered alternative costs, the user walks away knowing something real about how their site works. Which is exactly how I learned WordPress.
That is the definition of a nice-to-have AI feature. It is not solving a technical problem. It is solving an education gap with a shortcut. And shortcuts that replace understanding are not features. They are debt. Technical Debt. Furthermore, we know how WordPress users and developer feel about technical debt.
Similarly, the ‘one plugin, all the things’ pitch is coming. We have already seen the template. Jetpack built it. I have publicly said I think Jetpack is a great plugin in theory, and with the right leadership it could be better than ever. But Jetpack is also the clearest example in our ecosystem of why ‘one plugin to rule them all’ sounds great until you are actually using it. I have preached to the WordPress community for years that one plugin should do one thing well. Now we are about to watch the same consolidation happen with AI features, and we are going to call it innovation.
You Cannot Guardrail AI. The WordPress Agentic Web Depends on Understanding That.
Over the past year I have been asked multiple times to evaluate SaaS products built around the premise of AI-powered WordPress support. Install a plugin, connect your site, and the AI handles updates, fixes conflicts, patches errors. In theory it sounds like the future. In practice, every single one of them failed to work the way they were intended.
This is not a knock on the people building them. It is a fundamental problem with the premise. You cannot fully guardrail AI. Even when you write explicit instructions telling it not to go outside certain boundaries, it does. We saw this play out publicly when an X account lost years of posts in a single Saturday because an automated process did exactly what it was not supposed to do. I have seen my own Claude models do this. The only way to catch it is to run a dry run first, review the outcome, and actually understand what is about to happen before it happens. That requires a human who knows what they are looking at.
Moreover, if Yoast throws an error, the answer is not an AI agent applying a band-aid to Yoast’s code. The answer is understanding why Yoast is throwing the error. Is it a conflict? A bad update? A hosting issue? A deprecated function in your theme? An AI agent that patches over that without understanding the stack is not fixing anything. It is burying a problem that will surface later in a way that is harder to diagnose. That is not support. That is liability.
WordPress 7.0 Got the Architecture Right. Now the Plugin Ecosystem Needs to Catch Up.
Here is what gives me genuine optimism. WordPress core made the right call. WordPress 7.0 is not shipping a built-in AI writer. It is shipping the Abilities API and an AI Client, a standardized way for developers to build AI-powered tools that work across the entire ecosystem. In one of the early release candidates, we got a first look at a connectors screen showing three provider plugins: AI Provider for Anthropic, AI Provider for Google, and AI Provider for OpenAI. That screen did not make it into RC2, but the architecture behind it is sound.
Core gave the ecosystem the right building blocks. A structured API. External AI relationships. Replaceable interfaces. Portable workflows. In other words, core built exactly what I have been arguing for across this entire series. The question now is whether the plugin ecosystem is paying attention or whether they are going to look at those building blocks and ship a chat widget anyway.
As I wrote in part two of this series, I have been doing exactly this already. Claude Desktop connected to my WordPress site through the WP Abilities API and an MCP adapter. No dashboard AI widget. No AI writing plugin. My words, my process, my tools. One connection that does what five plugins would otherwise fight over. And because the AI relationship lives in my Claude account and not inside any plugin, nothing about my WordPress setup affects my workflow. That is what the WordPress agentic web actually looks like when it is built right.
Teaching Is How We Actually Get There
The path to the WordPress agentic web is not paved with AI features that do things for users. It is paved with users who understand what WordPress can do and know how to ask for it. Those two things are not the same, and the difference matters enormously.
A user who knows what a custom post type is can talk to an AI agent and get exactly what they need. A user who has only ever clicked a button that created one for them cannot. The first user is ready for the agentic web. The second user is ready for the next upsell.
Eight years of co-organizing a WordPress Meetup taught me one thing above everything else. People are not struggling with WordPress because it is too hard. They are struggling because nobody slowed down long enough to show them how it works. Every time someone did, the look on their face was the same. Not relief. Possibility. That is the user who is ready to work alongside AI tools in a meaningful way. That is the user the WordPress agentic web actually needs.
So if you are a plugin developer thinking about shipping an AI feature, ask yourself one question before you write a line of code. Does this make the user more capable, or does it make them more dependent on me? If the answer is the second one, you are not building the agentic web. You are building a subscription.
WordPress Can Be the Agentic Web. Here Is What That Actually Requires.
Token costs. Lock-in. Dependency. Those are the three things nobody was talking about when this conversation started. They are connected. They are all symptoms of the same root problem. We keep building AI into WordPress like users cannot learn, cannot grow, and cannot be trusted with real tools.
They can. They just need someone to show them.
If you are navigating all of this, whether you are a site owner trying to figure out what AI features are actually worth your time, or a developer trying to build something that genuinely helps people, I can help. I have spent 15 years doing real WordPress support, not the kind that patches over problems, but the kind that actually explains what happened and why. That is still the best tool we have. And it works a lot better than a chat widget.
Get in touch. Let’s figure it out together.
Leave a Reply