Most AI plugins for WordPress forget things. You spend a session teaching an assistant your store’s tone, your refund rules, which products need careful wording, and the next day it starts from zero. Or it does remember, but only inside its own database table, where nothing else on the site can read it back.
That second case is the one developers keep creating, and it’s the problem WordPress.com set out to fix with WordPress Guidelines, the agent-context system that shipped in Gutenberg and is proposed for Core. I came to it through their post on WordCamp Agent, the Telegram assistant they built for WordCamp Europe 2026 in Kraków. The bot is a fun demo, but what I want to look at here is the architecture underneath it.
The problem with every plugin shipping its own memory
The announcement makes an argument I agree with: without a shared system, every plugin ships its own memory store, its own permissions model, and its own REST surface, and that’s the kind of fragmentation WordPress has mostly avoided. Anyone who has untangled a site’s exports knows the pattern. Contact form plugins keep submissions in a private table, SEO plugins keep their own meta, page builders keep their own template stores. Each one works alone, and together they make backups, migrations, and deletion requests miserable.
The reflex fix is to roll your own: a custom table, an admin screen, a REST endpoint, done in an afternoon. It holds up until two agents exist on one site. The shop owner tells the support assistant about a return policy and the content assistant never learns it. Facts about the same user sit in three places with three deletion paths. When Core later ships a standard API, you own a migration nobody planned for. It fails because it solves the problem for exactly one plugin.
If you already shipped a memory table, build a bridge rather than starting a rewrite. Read your old rows, write them as guideline content, and keep the table running until the Core API lands. Ripping it out early gives you two broken things instead of one working one.
What WordPress Guidelines stores
Guidelines keeps four kinds of agent-facing knowledge as ordinary WordPress content:
- Instructions: site-wide guidance that shapes how an agent behaves. WordCamp Agent gets its personality here.
- Skills: reusable capabilities, like looking up the live schedule. Swap the skill and the behavior changes with no deploy.
- Memory: facts the agent picks up while working with you, such as which sessions you care about or what accessibility needs you have.
- Artifacts: work in progress, notes and drafts you’ll come back to.
All four live in one wp_guideline custom post type, split by a wp_guideline_type taxonomy, with native revisions and the standard REST API on top. That’s the part I like most, because it’s a custom post type doing custom post type work. If you’ve read my earlier argument about custom post types as a persistence layer, you know what that buys: capabilities and endpoints without new infrastructure.
The WordCamp Agent demo makes the model concrete. Message the bot once and you’re added as a contributor to the site behind it. Your preferences and notes become real posts tied to your user, private to your account and deletable whenever you want. The bot itself needed no custom application code; every behavior is a published guideline. For a deeper technical walkthrough, Grzegorz Ziółkowski’s post on the Core proposal is the one to read. The make.wordpress.org announcement covers how it first landed as a Gutenberg experiment in 22.7, before the production rollout the demo runs on in 23.2.2.
Check the capability mapping first
Before you build anything, sit with the permission model, because it decides what your code will see. Administrators see everything; contributors, authors, and editors get read and edit on their own private guidelines; subscribers are blocked at the post-type level.
Two consequences follow. First, empty results look like lost memory. If your integration queries from a cron job with no logged-in user, or authenticates with an application password belonging to a subscriber, you won’t get an error; you’ll get an empty set. An assistant that seems to have forgotten everything may just be running under the wrong role. Reproduce the query with a real contributor account before you conclude that anything is broken.
Second, memory is scoped per user by default. If you imagined one shared knowledge base for the site, the privacy model ties most guidelines to their author instead. Site-wide behavior belongs in instructions, which administrators manage, and per-user facts stay with the user. Getting that split right at the start saves you a rewrite later.
How to write against it today without breaking sites
Guidelines is not in Core yet, so guard everything you write. The cheap guard is a post type check:
function bbioon_get_guidelines() {
// Guidelines is a Gutenberg experiment, not Core yet.
if ( ! post_type_exists( 'wp_guideline' ) ) {
return array();
}
return get_posts( array(
'post_type' => 'wp_guideline',
'post_status' => 'publish',
'posts_per_page' => 50,
) );
}From there, filter with the wp_guideline_type taxonomy once you know the registered term slugs. I’d list them with wp term list wp_guideline_type on a test site before hardcoding a slug into a query, because the naming may still shift on the way to Core. WP-CLI is also a quick way to see what’s there: wp post list --post_type=wp_guideline --fields=ID,post_title,post_author shows how much of the memory is per-user content.
When I’d still keep a separate store
Not every memory belongs in wp_posts. If your agent retrieves by semantic similarity, you need embeddings, and MySQL will store vectors but it won’t search them well. Keep a real vector store or a dedicated table for retrieval, and let guidelines hold the human-readable layer, the same split I ran into with knowledge graphs and post meta.
Volume and retention push the same way. A site that logs thousands of interaction summaries a day will fatten the posts table and pile up revisions. Memory entries that hold personal data may need a retention rule of their own, and a separate table with a cleanup job is easier to audit for that. I don’t know yet how Core intends to handle retention for memory entries, so treat the question as open until the proposal answers it.
This is still an experiment staged for a Core proposal, and experiment-stage schemas move. Don’t ship a client feature that writes wp_guideline posts yet. Turn the experiment on in a staging copy, test what a contributor can read through an application password, and follow the Core ticket before you commit to the API. And if you’re deciding whether your plugin should adopt Guidelines or keep its own store, I’m glad to look at what you’ve built and work through the trade-offs with you.
