WordPress Knowledge Post Type Proposed for 7.1 Core

Twenty years of WordPress has taught me one durable lesson: the boring parts are the parts that age well. Post types, taxonomies, revisions, capabilities. The flashy parts come and go. The boring parts compound. So when a merge proposal lands that says, in effect, “let us add one more boring primitive and let everyone build on it for a decade,” I pay attention.

That is what happened on Monday. Greg Ziółkowski posted a proposal on Make/Core to merge a new custom post type called wp_knowledge into WordPress 7.1, with Guidelines as the first feature built on top of it. On the surface it looks small. In practice, it is one of the more important architectural decisions the project has made this year, because it stakes a claim on where the durable, author-facing and agent-facing site memory lives.

It is not an AI feature. That is part of why it is interesting. It is a place to put the things you would otherwise hand to an AI feature.

What is actually new

On June 22, 2026, Ziółkowski published the Guidelines built on Knowledge merge proposal on Make/Core. The proposal asks the project to commit, before the WordPress 7.1 Beta 1 freeze on July 15, to a new private custom post type and its supporting taxonomy.

The shape of the primitive:

• Custom post type: wp_knowledge. Non-public, headless, REST-only, authenticated.
• Taxonomy: wp_knowledge_type. Three built-in type slugs ship with the first version: guideline, memory, note.
• Capability namespace: *_knowledge_item (think read_knowledge_item, edit_knowledge_item), graded so administrators manage site-wide entries, contributors and authors only manage their own private rows, and subscribers see nothing.
• REST routes: /wp/v2/knowledge for the collection and a read-only /wp/v2/knowledge/guideline-scopes registry.
• Revisions on, autosave endpoints off.

The three built-in types each have a specific job in the proposal. A guideline is “a standard, pure text that is the source of truth” for things like voice, tone, or image direction. A memory is “durable context explicitly saved or approved for future use.” A note is “private freeform working text.” Three jobs, one storage layer, one access model.

The proposal is explicit about what it is not. “No AI provider, no model, no retrieval algorithm, and no autonomous memory system.” The core change is the storage primitive. The consumer-side work — the Guidelines admin UI, retrieval, agent wiring — stays in Gutenberg.

The implementation is already in flight. The core counterpart is wordpress-develop PR #12201, opened by Ziółkowski and linked to Trac ticket #65476. The Gutenberg side ran its experiment in PR #79149 with the migration follow-up in #79263. The pattern is the one we have seen with the Abilities API and the AI Client work over the last cycle: prototype in the plugin, harden, then merge the storage layer into core.

One detail that should not get lost in the noise: the proposal asks the project to lock the names — wp_knowledge, wp_knowledge_type, the three type slugs, the capability namespace — at Beta 1. After that they become long-term compatibility commitments. That is the right question to argue about now, before they freeze.

Why it matters for WordPress and WooCommerce people

This is where most readers will ask, fairly, “why should I care about another custom post type?” Two reasons.

First, every serious agency and product team I know has been quietly stitching together their own version of this for the last eighteen months. We keep brand voice in a PDF. We keep image direction in a shared doc. We keep client-specific dos and don’ts in a wiki the editorial team forgets exists. We keep “do not auto-translate this term” rules in a plugin’s settings table. None of that is queryable from the editor. None of it is portable. None of it survives a CMS migration. A wp_knowledge post type with revisions, capabilities, and a REST endpoint solves that without inventing a new spec. It is just a post, with the post infrastructure WordPress already does well.

Second, this is the substrate the AI features in 7.1 will eventually sit on. The roadmap is honest about that direction: AI Client streaming, the Abilities API, agent-friendly capabilities. If you want an editor or an agent to “follow the house style,” you need somewhere durable to keep the house style. Storing the rules in code is brittle; storing them in a flat options table is worse. Storing them as posts means you get revisions for free, capability checks for free, REST access for free, and a migration story that is identical to every other post type on the site.

For WooCommerce teams the angle is more concrete. A product catalog with thousands of SKUs needs editorial guidelines too: tone for product descriptions, image aspect ratios, restricted claim language for regulated categories, terminology rules across languages. Today that lives in a Notion doc nobody opens. With a Knowledge post type and an Abilities-backed agent, those rules can be referenced at write time. That is a real workflow improvement, not a demo.

The risk, of course, is overreach. A poorly designed primitive that ships into core never really leaves. wp_block taught us that lesson, in a good way. wp_navigation taught us the same lesson in a more complicated way. Whatever ships in 7.1 will be with us for years.

What I would do (or not do) about it

Three things, in order.

One: if you have an opinion on the names, post it on the proposal thread this week. The names are the part that locks in at Beta 1. “Is wp_knowledge the right long-term name for the primitive?” is exactly the question Ziółkowski put on the table, and it is the kind of question where senior practitioner feedback matters more than benchmark numbers. I would personally argue for keeping the names exactly as proposed — they are descriptive without being clever, and “knowledge” is the rare word that survives in both author-facing and agent-facing contexts.

Two: do not build on the Gutenberg experiment as if it were stable today. The current PRs are in motion. If you are scoping a client project that wants editorial guidelines or agent memory in the next eight weeks, scope it against the merged core API, not the plugin-side prototype. The risk of building on the plugin shape today and rewriting at Beta 1 is real.

Three: start collecting the content you would put in there. This is the boring, useful work. For every client whose voice and content rules currently live in a Google Doc, draft what the guideline entries would look like as short, declarative posts. Voice. Tone. Banned phrases. Image direction. Terminology. The day this primitive lands you will be ready to migrate, and the migration will be a single REST script, not a project.

What I would not do is treat this as “an AI feature” and either get excited or skeptical accordingly. It is a storage primitive. The fact that AI features will eventually consume it is real, but the value of having one clean place to store editorial truth would be obvious in 2015 too. The proposal is intentionally restrained, and the restraint is the strongest thing about it.

The right test for any new core primitive is whether you would still want it if the buzzword on the cover changed. Strip “AI” off this proposal and you have a versioned, capability-aware, REST-accessible store for the rules your editorial team already lives by. That passes the test.