WordPress Wants to Bake AI “Memory” Into Core | Developers Aren’t Buying It

WordPress’s wp_knowledge post type merge proposal for 7.1 is splitting developers. Here’s what it does, why it’s controversial, and what it means for your site.

Key Takeaways

  • A new wp_knowledge custom post type and wp_knowledge_type taxonomy, merged into WordPress core for version 7.1.
  • Who proposed it? Core committer Greg Ziółkowski, via a Make/Core merge proposal published June 22, 2026.
  • What does it store? Three content types: guideline (editorial standards), memory (saved context), and note (private drafts).
  • The proposal frames it as author-facing and agent-facing, though critics say the framing doesn’t match the technical spec.
  • When does it lock in? Names and API surface freeze at WordPress 7.1 Beta 1 on July 15, 2026 (Tentative)
  • Developer reaction? Largely negative!
  • One of the prime concerns regard to the benefit of wordpress.com enterprise users, not the regular users.

WordPress core is about to gain a permanent, built-in storage layer for AI instructions. Unfortunately, most of the developers who’d have to live with it don’t think it belongs there.

What Is the wp_knowledge Custom Post Type?

The wp_knowledge post type is a new, non-public, REST-only content store proposed for WordPress 7.1.

It’s designed to hold structured “knowledge” about a WordPress site like the brand voice, editorial rules, image guidelines, and persistent context.

It’s stored in a format that both human contributors and AI agents can read through a shared taxonomy called wp_knowledge_type.

Unlike the standard Posts and Pages content types, wp_knowledge entries aren’t meant to be published or displayed.

They’re headless, authenticated-access-only records that sit behind the scenes, feeding editorial standards to anyone (or anything) building on top of a WordPress site.

How the Proposal Actually Works?

The technical spec, published by core committer Greg Ziółkowski on the Make WordPress Core blog on June 22, 2026, is more specific than the original February concept that sparked the initial backlash.

Three built-in type slugs ship in the first version:

  • Guideline: a standing rule, like brand voice, tone, or image style
  • Memory: durable context a user has explicitly chosen to save
  • Note: private, freeform working text

Access is capability-graded: administrators manage site-wide entries, while contributors and authors can only manage their own private rows.

Subscribers see nothing.

The REST routes (/wp/v2/knowledge) expose the collection to plugins, themes, and AI tools alike, and the proposal is explicit that it ships no AI model, provider, or retrieval logic of its own.

It’s purely a storage primitive that other tools can build on.

The Guidelines feature: the first thing built on top of wp_knowledge – already exists as an experimental Gutenberg feature covering five scopes: Site, Copy, Images, Blocks, and Additional (accessibility rules, linking practices, and anything else that doesn’t fit elsewhere).

Why Developers Are Pushing Back?

The reaction across Make/Core comments and the WordPress developer community has been overwhelmingly critical, for 6 recurring reasons:

  1. It should be a plugin, not core. Critics argue a storage primitive this specific doesn’t need to live in every WordPress install by default.
  2. Adding another post type, taxonomy, and capability namespace expands the codebase every site carries, whether it uses the feature or not.
  3. Commenters cite native multilingual support as the far more urgent missing feature – one WordPress still doesn’t have natively after years of requests.
  4. Several developers, including core contributor Aaron Jorbin, feel the proposal lays a foundation but isn’t fully baked for a core merge this cycle.
  5. The proposal calls the feature “author-facing and agent-facing,” but the original GitHub spec described it almost entirely in terms of AI-agent use cases, barely mentioning human editors.
  6. Some suspect the feature primarily benefits Automattic’s WordPress.com enterprise customers rather than the average self-hosted site owner.

This Isn’t WordPress’s First AI-Related Pushback in 2026

This marks the second time in the WordPress 7.x cycle that a headline feature has drawn organized developer resistance.

Real-time collaboration (RTC) was pulled from WordPress 7.0 roughly two weeks before release after core committers questioned whether the full feature set belonged in core at all.

It is a debate that’s still unresolved heading into 7.1, where RTC remains framed around “big, open strategy questions” rather than a firm ship date.

The pattern with wp_knowledge follows the same trajectory WordPress used for the Abilities API and AI Client work shipped in 7.0: prototype as a Gutenberg plugin, harden it through real-world testing, then propose merging the storage layer into core.

WordPress.com engineer Artur Piszek (you can learn more about him here) has already used the Guidelines system in production, building a Telegram support agent for WordCamp Europe 2026.

It stored the entire personality, schedule logic, and user memory as published guideline entries rather than custom code – one data point supporting the case that the primitive has real utility beyond content marketing.

What Happens Next

The technical decision isn’t finalized. WordPress 7.1 Beta 1 lands July 15, 2026, and that’s the point at which the wp_knowledge name, its taxonomy, the three type slugs, and the capability namespace all become long-term compatibility commitments if the merge proceeds.

Between now and then is the practical window for developers to weigh in before the API surface locks. WordPress 7.1 itself is scheduled to release August 19, 2026.

What This Means If You Run a WordPress Site

If the merge proceeds as proposed, most site owners won’t notice anything change on day one – wp_knowledge entries are non-public and won’t appear anywhere on your front end.

The practical impact shows up downstream: SEO and AI plugins will likely start writing editorial standards, author credentials, and content-verification rules directly into this structure.

This could feed machine-readable trust signals (like Schema.org’s publishingPrinciples property) straight into your site’s markup.

This is clearly relevant for E-E-A-T signaling as AI Overviews and answer engines increasingly check for documented editorial process, not just author bylines.

Post Reference: New AI Feature Doesn’t belong in core.

Leave a Reply

Your email address will not be published. Required fields are marked *