When I wrote about WordPress Core AI 7.1 planning a few weeks ago, I called Guidelines my top personal priority and mentioned memories and skills as future primitives this work would unlock. This post explains what I mean by memory in this context, why I think it belongs in core rather than in a plugin, and how the wp_guideline CPT can grow to hold it. The technical groundwork is in progress now in Gutenberg PR #78296, currently at the access refinement stage, with the larger vision tracked in issue #77230.
Where Guidelines is today
Guidelines shipped as a Gutenberg experiment in version 22.7 in March 2026. The announcement on Make Core AI walks through the first release in detail. The short version: site administrators get a single Settings page where they define editorial standards across categories like Site, Copy, Images, Blocks, and Additional. The data lives in a custom post type, originally registered as wp_content_guideline, with each category stored as structured post meta.
Revisions, JSON import and export, and a REST API at /wp/v2/content-guidelines come from day one. In the 22.7 release, the endpoint was intentionally conservative: it required manage_options, so on a default site only Administrators could read or write Guidelines. That was the right call for an admin-curated singleton. It stops being the right call the moment agents start writing rows on behalf of individual users, which is what the broader model is for. The access policy PR linked above is the work that makes that broader model safe.
The renaming before release is worth noting. The team decided during development that the concept extends well beyond editorial content, into design guidelines, coding standards, and more, so “Content” was dropped from the public-facing name. The CPT slug followed the same path, settling on wp_guideline as the broader work in the tracking issue linked above took shape. The rename, taxonomy registration, and type-aware CPT work have already started that broadening. Same CPT, broader purpose. The rest of this post is about why that broadening belongs in core and what shape it should take.
Three kinds of memory
Most agent memory systems focus on two types:
- Episodic memory: what happened.
- Semantic memory: what is known.
Production agents also need a third. Procedural memory stores how things should be done. That means learned workflows, conventions, tool-use habits, the process knowledge an agent applies consistently. A coding assistant that knows how a team structures pull requests, which test commands run before merging, and how release notes get written is exercising procedural memory. This framing is from Mem0’s State of AI Agent Memory 2026, and once you adopt it, the design space for WordPress gets much clearer.
WordPress already does episodic memory well, just not under that name. Post revisions are episodic. They record how a specific document changed over time. Jetpack’s Activity Log, available on Jetpack and WordPress.com sites, is episodic at the site level. It records what happened on the site, when, and who did it, across posts, plugins, themes, settings, and more. Both already store this information, and the agent should read from them rather than duplicate it.
Semantic memory is already partly covered. The Guidelines feature, as it exists today, is already a form of semantic memory. It stores what the site is, like brand voice, audience, copy standards, and image conventions, in a structured way an agent can load into every prompt. That covers the admin-curated side. What it doesn’t cover is the agent-written side: facts and observations an agent accumulates over time and wants to recall in future sessions. That’s the gap the memory type added by the currently open PR is meant to fill.
Procedural memory is the kind WordPress has nothing for today. AGENTS.md or CLAUDE.md exist in the coding-agent world. Themes already encode design constraints in theme.json and structural intent in templates, but there’s no first-class way for a site to say “when generating image descriptions on this site, follow this process” in a form an agent can discover, version, and load on demand. That’s skill in the planned taxonomy.
Why core, not a plugin
By core, I mean the shared persistence and permission primitive should be owned by WordPress and incubated through the usual feature path, not that every AI behavior needs to ship in WordPress itself.
Start with authorization. Memory is data. Data needs the same access controls everything else in WordPress has. The mature application-level authorization model, with roles, capabilities, meta-capabilities, and post authorship, already covers what memory needs. The memory store should reuse it, not reinvent it next to it. A plugin is the natural place to prototype this kind of work, and the AI plugin and Gutenberg plugin experiments have done exactly that for adjacent AI workflows and Guidelines integration. The question is what happens when the shared persistence primitive is ready. If memory ships as a plugin permanently, it has to either build a parallel access control system or fall back on edit_posts.
Then interoperability. The WordPress AI ecosystem already has multiple moving pieces. The Abilities API, the MCP Adapter, the WP AI Client. If memory storage lives in a single plugin’s custom schema, every other piece has to integrate with that plugin. If memory storage lives in core as a CPT with REST endpoints, every piece fits together naturally. An ability can read a memory. A skill can be exposed as an MCP tool. The WP AI Client can load relevant memories into a prompt. None of that requires a plugin dependency graph.
Privacy belongs in the same shape. WordPress already has personal data export and erasure flows, and storing memory as first-class WordPress content gives a clear path to integrate with those flows from the start. A memory written for a user is personal data the moment it’s written, and the request to export or erase it should reach the memory store the same way it reaches posts and comments. Revisions, authorship, statuses, and REST permissions give a lot of the compliance surface area we would otherwise have to rebuild.
And durability of the model itself. The Guidelines CPT was the right first step, and a parallel CPT for each future type, like wp_skill, wp_memory, or wp_plan, would scatter the model across many slightly-different storage shapes that need parallel maintenance. One CPT with a taxonomy marker is the pattern WordPress has converged on for similar problems (wp_template with wp_theme, wp_block with wp_pattern_category, nav_menu_item with nav_menu). It’s the standard WordPress answer, and it scales.
The architecture
Imagine a site where an editor tells the assistant, “Write product summaries in our release-post voice, avoid emoji for this author, and always include compatibility notes.” The release-post voice belongs in content. The author preference belongs in memory. A draft outline created during one request belongs in artifact. The repeatable process for turning product changes into a release summary is what a future skill type would hold.
Keep wp_guideline as the single CPT, classify rows by a wp_guideline_type taxonomy, and let each type evolve its storage and lifecycle independently while sharing the access model and REST surface.
The current registry already has content for the original singleton and artifact as the default for episodic working material like drafts and intermediate outputs the agent produces mid-task. The access policy PR adds memory, for facts and observations an agent accumulates over time and recalls in future sessions. Three more remain future considerations: skill for procedural knowledge that should be applied consistently, plan for multi-step task documents with state and history, and instruction for explicit directives. My longer-term view is that skill and instruction might even make the content type obsolete as a conceptual model. Editorial standards split naturally into reusable procedures and explicit directives once those types exist, and a single bag of admin-curated guidance becomes less useful than two well-scoped ones.
Each type carries a different lifecycle. content is site-wide, admin-curated, and potentially transitional as a conceptual type. memory and artifact are private to their author, many per site. skill is reusable across sessions and loadable on demand. plan is task-scoped and archived when the work completes.
Storage shape differs by type. The original content type uses structured post meta keyed by category, under a reserved singleton title, because it’s the one row per site that captures site-wide standards. The newer types use standard post fields. The title gives a discoverable name. The excerpt provides a short description an agent can use to decide whether to load the full content. The post_content holds the body. That difference is fine. The REST controller can branch on type, with each type defining its own schema and behavior while still sharing the same underlying object model. Native WordPress revisions give every type versioning for free.
The access model landing now
The access policy PR reworks the capability mapping because the original setup aliased every guideline operation to a core post capability like edit_posts, publish_posts, and so on. That works for the admin-curated content type, but it’s exactly wrong for memory and artifact, which need to be private to their author. Any user with edit_posts, which means every Contributor and Author, could otherwise read another user’s memories. And post_status = private alone doesn’t help, because Editors and Administrators have read_private_posts by default.
The fix is a synthesized *_guidelines capability namespace resolved at runtime. The goal is straightforward: each user sees only their own private memories, admins keep full control, and the rules are enforced consistently whether the request comes through the admin UI or REST.
Administrators receive every guideline primitive. Contributor, Author, and Editor receive baseline read_guidelines and edit_guidelines plus CRUD on their own private rows only. Subscribers are blocked at the post-type door.
REST per-item reads route through read_post, which maps to the right *_guidelines primitive based on the row’s status and ownership. Non-publishers can only set status: private, and creates default to private instead of draft.
The PR turns off the native post-type admin UI (show_ui: false) because the management surface continues to flow through the Settings → Guidelines page, gated by manage_options. Taxonomy term creation and assignment open up to Contributor+ via edit_guidelines so an agent flow can introduce a new type slug on first use, while term administration and deletion stay Administrator-only. The default type registry, originally just content and then extended with artifact, now includes memory as the third default once the current PR lands. Allowing broad term creation here isn’t a design statement, it keeps the system from breaking when an agent encounters a missing term. The meaningful types should still come from a registry that plugins and agents both target, so different parts of the ecosystem don’t invent incompatible slugs for the same idea.
This is the foundation. Once it’s in, the rest of the vision becomes incremental work on top of a model that already handles authorization correctly. None of this implies that agents can silently remember anything. Product layers still need to handle consent, review, expiration, deletion, and user-facing inspection. Core owns the storage primitive. The UX of remembering, reviewing, and editing is product work.
What’s still ahead
REST maturation for the newer types. The broader /wp/v2/guidelines collection now sits alongside the dedicated /wp/v2/content-guidelines singleton route, so the basic collection shape is no longer the hard part. What still needs to mature is the per-type behavior layer: which fields each type requires, which lifecycle rules each type enforces, and how plugin- and theme-provided defaults are represented. The work is doing it without breaking the existing content-guidelines route.
A plugin and theme registration API, something like wp_register_guideline(), so themes and plugins can ship default skills and other read-only types, the way themes already register templates. File-based theme defaults fit here too. A theme can ship a default brand voice or a default content guideline that the site inherits unless overridden. This is what turns the foundation into something the whole ecosystem can build on. Plugins shipping AI integrations get a place to publish their skills, sites can override defaults with site-specific versions, and agents discover everything through one REST endpoint.
Scoping above the CPT. The CPT itself is site-scoped, which is the right primary boundary. Agents working on behalf of users need per-user and sometimes per-conversation scoping layered on top, and that’s where the new access policy starts paying off. Private and author-owned rows already give you (user, site) for free. Per-agent scoping, conversation context, and any cross-site preference layer belong above core in the consuming product.
Closing
Memory belongs in WordPress core because the hard parts of memory aren’t vector search or prompt assembly. They’re ownership, permissions, inspection, erasure, and interoperability. Those are WordPress problems, and WordPress already has mature answers for them. The Guidelines CPT is the place to grow that primitive.
If you’re working on adjacent WordPress AI surfaces, I’d love to hear how this lines up with what you’re building. The pieces I’m most curious to discuss are where the type boundaries should settle, which behaviors belong above core, and what consent and review UX should exist before agents start writing memories at scale. The shape of all of this is still being worked out, and the conversation belongs in the open. An official proposal to merge Guidelines into WordPress core is on the table, and feedback gathered here will directly shape how it comes together.
Leave a Reply