Why WordPress Developers Are Pushing Back on a New AI Feature in Core

A proposal to bake a new AI-focused feature straight into WordPress core has hit a wall of developer objections. The feature, a Knowledge Custom Post Type, is meant to act as a central store of guidelines about your website that editors, contributors and AI agents can all read from. It's already in the Gutenberg plugin as an experiment. But when the plan to merge it into core went public, the response from the developer community was overwhelmingly negative, with many arguing it's solving a problem most site owners don't actually have.

If you run a WordPress site, this is worth understanding. Not because the feature will land tomorrow, but because it tells you a lot about the direction core is taking, and the tension between AI ambitions and the everyday needs of people who just want their site to work.

Key takeaways

• The proposed Knowledge Custom Post Type would store site-wide rules (brand voice, image style, content standards) in one place for humans and AI tools to reference.
• It was proposed in February 2026 and added to the Gutenberg plugin a month later as an experimental feature.
• Developers gave it a thumbs down, with at least six separate objections, including that it belongs in a plugin, not core.
• The public proposal frames it as "author-facing and agent-facing", but the GitHub spec describes it as built for AI agents, with no mention of usefulness for humans.
• This is the second feature in WordPress 7 to face strong pushback, after Real-Time Collaboration in 7.0.

What's actually being proposed

WordPress has two built-in content types: Posts and Pages. On top of those, plugins can add Custom Post Types (CPTs) for specific jobs. WooCommerce, for example, uses a custom post type called "product" so shop owners can manage their catalogue. CPTs are a normal, well-established way to extend WordPress.

The new idea is a Knowledge Custom Post Type. It was proposed in February 2026 and, a month later, integrated into the Gutenberg plugin as an experimental feature. The plan is to merge it into core so everyone working on a site, humans, AI agents, tools and plugins, can read a shared set of guidelines.

The feature covers several knowledge types:

• Site, your site's goals, personality, target audience and industry. Foundational context any tool or contributor can reference.
• Copy, tone, voice, brand personality and vocabulary preferences. An editorial style guide living inside WordPress.
• Images, preferred image styles, colours, moods and subjects to include or avoid.
• Blocks, per-block-type rules. For example, that Paragraph blocks should favour short sentences, or that Image blocks should always include descriptive alt text.
• Additional, anything else: accessibility requirements, linking practices, formatting conventions, or rules that don't fit the categories above.

On paper that sounds tidy. A single home for your brand rules that both your team and any AI tooling can pull from. The trouble is whether it belongs inside WordPress itself, and who it's really for.

The gap between the pitch and the spec

Here's the part that set people off. The public proposal presents the feature as something humans and AI will both use. But the GitHub repository for the feature tells a different story. It positions the thing squarely for AI:

"The Guidelines CPT stores site wide editorial rules, brand voice, copy standards, image guidelines. This is one type of instructional content a site needs, but not the only one. As AI-powered tools integrate with WordPress, a recurring need is emerging for sites to store different kinds of persistent, structured knowledge that shapes how agents interact with the site."

Usefulness for humans isn't mentioned once on that page. That's the crux of the objection. There's a real gap between how the feature is sold publicly and what the technical spec actually describes. When the marketing says "for everyone" and the engineering says "for AI agents", it raises a fair question: does anyone in core genuinely know who this is for or how it'll be used?

That single inconsistency is one reason out of at least six developers gave for why the proposal feels rushed and unnecessary.

The six objections developers raised

The proposal was discussed in the private Dynamic WordPress Facebook group, where 29 comments came in overwhelmingly against it. Across that discussion and the official announcement, the objections boiled down to six points.

Objection	What developers are saying
It should be a plugin	This is exactly the kind of thing CPTs in plugins were made for. It doesn't need to live in core.
Core is already bloated	Adding more functionality just piles on weight that most sites won't use.
There are bigger priorities	Native multilingual support was unanimously cited as the most important missing feature, ahead of this.
It feels half-baked	Doubts about whether the proposal had been properly thought through.
It's not really for users	Many felt this is an AI feature dressed up as a user-facing one.
It benefits the wrong people	A few argued it helps Automattic's enterprise WordPress.com customers more than the average user.

Those are not fringe gripes. They're the kind of practical concerns you'd expect from people who maintain real sites for real clients and watch every new core feature add maintenance overhead.

What the commenters actually said

The pushback wasn't confined to a closed Facebook group. The official announcement on WordPress drew the same scepticism.

The commenter mrwweb put it plainly:

"I know it says this feature is provided for both 'author-facing and agent-facing' applications, but it feels like AI/LLMs are driving the conception of the feature. Further, the underlying assumption that 'Most sites already have content standards' does not strike me as accurate. That is a very real need and use-case, but I'm not sure it's one that would justify a new core feature on its own... I think there's a lot of promise in this feature, but I also wonder if it needs a broader lens that considers a fuller-range of use-cases, especially for humans."

Namith Jawahar was blunter:

"This looks like an unnecessary overreach. Better to let developers decide it for individual sites rather than force a post type onto everyone."

Aaron Jorbin was more open to the idea but flagged that it isn't ready:

"As is, this feels incomplete. I think it does set the foundation and with the time remaining before 7.1, I think this could become a great addition."

So it isn't pure rejection. Some see the potential. The consistent message is that it's not finished, the case for putting it in core hasn't been made, and the priorities feel off.

Why this matters for your site

You might be tempted to file this under "developer politics". Don't. Decisions about what goes into WordPress core affect every site running it, including yours.

Every feature added to core is code that ships to millions of sites whether they use it or not. More code means a bigger surface to maintain, more potential for bugs, and more to keep an eye on from a security and performance angle. That's the "bloat" argument in plain terms. The leaner core stays, the fewer moving parts there are to break on the average business site.

There's also the priorities point, and it's a strong one. Native multilingual support is something a huge number of site owners genuinely want and currently have to bolt on with plugins. When the community says that should come before an AI knowledge store, they're speaking for the people who actually run sites day to day. If you've ever wrestled with translating a WordPress site, you'll feel the force of that.

Then there's the AI question, which keeps cropping up across WordPress this year. There's a clear push to make WordPress friendlier to AI agents and tools. That can be genuinely useful. But features built primarily for AI, dressed up as features for humans, are a different thing. The worry isn't AI itself; it's whether the direction of core is being shaped by AI tooling and enterprise use cases rather than the needs of ordinary site owners. If you want a sense of where the platform is heading on this, our look at what native AI integration in WordPress 7.0 means for your site covers the wider picture.

This is the second 7.x feature to get questioned

This isn't a one-off. It's the second time in WordPress version 7 that a new feature has been strongly questioned. Version 7.0 saw developers query the necessity of Real-Time Collaboration (RTC), which was meant to be a focus of the Phase 3 collaboration work.

Two features in two releases drawing this kind of resistance suggests a pattern: an ambitious roadmap meeting a community that wants core to stay focused on fundamentals. That's healthy friction, honestly. It's the system working. Features get scrutinised before they ship to millions of sites, and the ones that aren't ready get sent back for another look. Aaron Jorbin's point about there being time before 7.1 is exactly that process in action.

What you should do (and not do)

For now, nothing urgent. The Knowledge CPT is experimental in Gutenberg and hasn't been merged into core. You don't need to touch anything, and you shouldn't go enabling experimental features on a live business site.

The sensible takeaway is broader than this single feature. WordPress is evolving quickly, and not every new feature will suit your site. The skill is in knowing what to adopt, what to ignore, and what to keep an eye on. That's where keeping core, plugins and themes properly looked after pays off, so you can make those calls deliberately rather than having changes wash over you. A solid website maintenance plan means someone is tracking these developments, testing updates before they hit your live site, and only turning on what actually helps your business.

And if your interest in this story is the AI angle, that there's a genuine case for storing brand rules in a structured way that tools can use, that's worth exploring properly rather than waiting for core to decide it for you. The point of a brand style guide that AI can read is to keep your voice consistent, and that's a strategy question first. Getting AI working sensibly in your business starts with deciding what you actually want it to do, then building around that.

The developers pushing back here aren't anti-AI. They're asking a reasonable question every business owner should ask of any new tool: who is this really for, and does it earn its place? That's a good habit to copy.