WordPress 7.1: The AI Knowledge Store Core Rejected

On 10 July 2026, a merge proposal that would have given WordPress its first shared place to store site knowledge was closed. It did not fail review, and nobody found a bug in it. It was reviewed with Matt Mullenweg and, in the words of the closing comment from Anne McCarthy (annezazu) on Make/Core, “this is not going to proceed for 7.1.”

If you run a WordPress site with an AI chatbot on it, that decision matters more than most 7.1 release notes. The proposal — wp_knowledge, a private custom post type with Guidelines built on top of it — was aimed squarely at the thing every AI plugin on your site is currently doing badly and separately: storing the text that tells a model how your site is supposed to sound, what it knows, and what it must never say.

WordPress 7.1 ships on 19 August 2026. It will not include that store. Here is what was proposed, why it stalled, and — measured on a live WordPress 7.0.2 install with 48 active plugins — exactly how much fragmentation the proposal was trying to end.

What was actually proposed

Greg Ziółkowski published the proposal on 22 June 2026. The pitch was a storage primitive, not a feature: a general place to keep author-facing and agent-facing knowledge as ordinary WordPress content, with the revisions, capabilities and REST access that ordinary content already gets.

The proposal was explicit about what it was not: no AI provider, no model, no retrieval algorithm, no autonomous memory system. No decay, no consolidation. Storage and access only. A skill type was deferred to 7.2, and plan and artifact types were left open.

The argument for putting it in core is worth quoting properly because it is the whole story: without a common primitive, every plugin ships its own storage, its own permissions model, and its own REST surface. The proposal compared it to wp_template, wp_block and nav_menu_item — core owning the primitive so the community stops building parallel solutions in the same domain.

Why it stopped

The closing comment is short and unusually direct about the reasoning. The priority for AI work is instead evals and benchmarking, tied to WP Bench. And the bar for new core features was stated plainly: nothing goes into core that is not already driven by “real-world adoption with impressive week to week growth,” with double digits given as the reference point. The proposal, as it stood, did not clear that bar.

That is a defensible position and it is also a significant one. It means core is not going to standardise this layer ahead of demand — the ecosystem has to prove the demand first, in plugins.

The second thing that stalled

Ten days after the Knowledge proposal, a separate merge proposal asked to expand the core Abilities API in 7.1 with three read-only abilities: core/read-settings, core/read-content and core/read-users. It drew immediate pushback from an Abilities component maintainer on two grounds — that core/read-settings had only just been released in the AI feature plugin (v1.1.0) and the other two were not released at all, and that committing to backward compatibility before the naming and schema conventions were settled was premature.

The naming point is not bikeshedding, and you can see why by looking at what is already registered in core. The three abilities core ships today are called core/get-environment-info, core/get-site-info and core/get-user-info. The proposal wanted read-. Two verbs, one registry, and a backward-compatibility promise waiting at the end of it.

The WordPress 7.1 Beta 1 announcement lists “Abilities API expansion” as continued refinement — improved querying, filtering and input validation. It names no new core abilities.

What is actually in core right now

Rather than infer this from release notes, we audited the install this site runs on: WordPress 7.0.2, 48 active plugins. Everything below is read from the running site, not from documentation.

The ratio is the interesting part. Core shipped roughly ten times more registry plumbing than AI surface: a 24 KB abilities registry with ten public functions, and a 2.5 KB AI client entry point with two. That is consistent with what the AI team has said repeatedly — the focus is primitives for plugin developers, not user-facing AI. It also means that if you want your WordPress site to have a brain, a plugin is still supplying all of it.

We wrote about the abilities registry in more depth when WordPress 7.0 landed, in WordPress 7.0’s AI core and what it means for chatbot plugins, and about who can actually call those abilities in our audit of MCP and AI agents on WordPress.

The fragmentation, measured

The proposal’s central claim is testable. If there is no shared knowledge primitive, plugins should be storing this material in a scattered set of places, each with its own access model. Here is that scatter on one real site.

Two of those option rows are almost comically on the nose. ab_mxchat_knowledge_prompt (3,964 bytes) and seo_ag_knowledge_prompt (3,638 bytes) are two different plugins each storing a block of instructional prose — brand voice, product framing, what to mention and what to avoid — as a single autoloaded string in wp_options. No revisions. No capability check beyond manage_options. No REST route. No way for any other tool on the site to read them.

That is precisely the record the guideline type was designed to be, implemented twice, badly, by two plugins that do not know about each other. Multiply that by the AI plugins on a typical WordPress site in 2026 and the proposal’s argument stops being abstract.

We are part of the problem, and here are our numbers

Auditing your own install is only useful if you report what it says about you. MxChat is one of the 48 plugins on this site, and it is the single largest writer to the options table.

Most of that is not knowledge — it is per-session state that should live in a table with an index and an expiry, not in the key-value store WordPress reads on every page load. 236 rows are autoloaded, which is the part that costs something on every request. It is filed for the plugin team rather than patched here, for the same reason we published the finding instead of quietly fixing it: a defect you fix silently is a defect nobody learns from. We took the same approach with the API keys sitting in this site’s options table, where our own core settings blob turned out to be the one storing its credentials correctly and two add-ons were not.

The honest summary: the WordPress ecosystem, us included, is storing agent-facing knowledge and session state wherever each plugin found convenient. Core proposed to fix the first half of that and decided not to yet.

WooCommerce makes the contrast instructive: it did not wait for a core proposal and shipped its own Agentic Commerce Protocol endpoints in 11.0, disabled by default. Plugin territory moves while core deliberates.

What this changes for site owners

Practically, three things.

Your chatbot’s knowledge is not portable, and will not be for at least a release. If you have spent hours writing system instructions, brand-voice rules and a knowledge base into a plugin, that content lives in that plugin’s storage shape. There is no core format to export it to and no standard route to read it from. Switching plugins means retyping. Ask any vendor you are evaluating whether their knowledge base has an export, and treat a missing answer as a lock-in cost.

Autoloaded prompt text is a real, small, permanent tax. 13,070 bytes on this install, unserialised into memory on every request including visits from crawlers. It is not a page-speed emergency, but it is a good proxy for whether a plugin was built by someone thinking about the whole site. A settings blob belongs in wp_options; a growing corpus does not.

Do not buy a plugin on the promise that core will standardise this. The bar Mullenweg set is real-world adoption first. Anything positioned as “ready for core’s knowledge API” is describing a thing that does not exist and has no shipping date.

What to watch

• 19 August 2026 — WordPress 7.1 ships at WordCamp US. Expect Abilities API refinement, not new core abilities.
• The AI feature plugin — this is where core/read-settings already lives and where core/read-content and core/read-users are heading first. If you want to see the future of agent access to WordPress, that plugin is the release channel, not core.
• 7.2 — the skill knowledge type was already deferred there, and the Knowledge proposal itself is closed rather than dead. If a plugin demonstrates the double-digit growth Mullenweg asked for, the argument reopens with evidence attached.
• WP Bench — evals and benchmarking are now the stated AI priority. That is a very different bet from shipping storage primitives, and it will shape what lands next.

Questions we got asked while writing this

Does WordPress 7.1 have AI features at all?

Yes, but not the ones the coverage implies. Core 7.0 already ships an AI client entry point and the Abilities API — both are on this install and both are real. 7.1 continues the Abilities API work with better querying, filtering and input validation. What it does not ship is the knowledge store, the Guidelines UI, or the three core/read-* abilities. If an article tells you 7.1 adds a Guidelines system, it is describing the June proposal rather than the release.

Should I wait for core before setting up a chatbot knowledge base?

No. The proposal is closed for 7.1, the deferred pieces target 7.2 at the earliest, and the stated condition for reopening is ecosystem adoption that has not happened yet. Waiting costs you a year and buys you nothing. Set it up in a plugin, and make export a requirement when you choose which one.

How do I check my own site for this?

Two WP-CLI commands. wp option list --search="*prompt*" --fields=option_name,autoload shows which plugins keep instructional text in the options table and whether it is autoloaded. wp eval 'echo count(wp_load_alloptions());' tells you how many options load on every request — ask the loader, not the autoload column, because WordPress 6.4 changed that column’s vocabulary to on/off/auto and did not migrate existing rows. On this install the column undercounts by thousands.

Is 159 non-core tables a lot?

It is normal for a commerce site and it is still the point. WooCommerce, Wordfence, Rank Math, Action Scheduler and Yoast account for most of them, and each set is well-built in isolation. The proposal was never about table count — it was about there being no shared answer to “where does this site keep what it knows,” and 159 tables plus 40 REST namespaces is what “no shared answer” looks like when you measure it.

The short version

WordPress core came close to owning the place your AI plugins keep their instructions, and pulled back. The reasoning was about adoption evidence rather than the design. Meanwhile, on a single ordinary WordPress site, 48 plugins have produced 159 non-core tables, 40 REST namespaces and 12 autoloaded blobs of prompt text with no shared way to read any of it — and the chatbot plugin whose team wrote this article accounts for 65% of the options table.

The fragmentation is real, it is measurable, and for now it is the ecosystem’s problem to solve one plugin at a time. If you want to see how we handle knowledge, embeddings and system instructions in practice, the MxChat documentation covers the storage and sync model, and MxChat Pro is the version most site owners run. We also keep a running log of what breaks on real installs — including the model IDs that stop working without warning.