WordPress 7.0 Put AI in Core. Do You Still Need a Chatbot Plugin?

WordPress 7.0 'Armstrong' shipped a native AI layer on 20 May 2026. Before you cancel your chatbot subscription, read this.

Published July 2026 | 9 min read | WordPress 7.0 AI · Chatbot Plugins · Developer Guide

What WordPress 7.0 Actually Ships: The AI Layer Explained

WordPress 7.0 'Armstrong', released on 20 May 2026, is the most architecturally significant release since Gutenberg. For the first time, WordPress core bundles a provider-agnostic AI Client — meaning WordPress itself can communicate with external AI providers without any third-party plugin acting as an intermediary bridge. That is a genuinely meaningful change. But understanding what it actually ships, and what it deliberately does not, is the difference between making a smart tooling decision and cancelling a subscription you still need.

The Abilities API: The Architectural Centerpiece

The Abilities API is the core of what Armstrong introduces. Developers register discrete tasks using wp_register_ability() and read the full registry back with wp_get_abilities(). Two classes do the work: WP_Ability represents a single registered capability and its metadata, and WP_Abilities_Registry is the shared registry every plugin writes into and reads from. If you want to confirm this on your own install, both are in wp-includes/abilities-api/ — this is a first-class core API, not a bolted-on feature.

The Connectors Hub

A new admin screen — Settings → Connectors, served by wp-admin/options-connectors.php — gives site owners a single place to store and manage credentials for external AI providers. Three provider presets ship by default: OpenAI, Google Gemini, and Anthropic Claude. The architecture is deliberately provider-agnostic, so additional connectors can be registered by plugins as the ecosystem matures. The goal is to end the situation where every AI plugin asks for its own API key in its own settings screen.

Client-Side Abilities and the Command Palette

Client-side abilities packages ship alongside the admin command palette (Cmd+K / Ctrl+K), which 7.0 extends across the interface rather than confining it to the block editor. The intent is that registered abilities become reachable from a keyboard prompt instead of a settings screen buried three menus deep. How much of your registry actually surfaces there depends on how each plugin registers its abilities — treat it as a direction of travel, not a finished feature.

The Canonical AI Plugin (Not Core)

An optional canonical AI plugin — separate from core — extends the base layer with practical editorial tools: image generation, title and excerpt drafting, and alt-text suggestions for media uploads. This is important: these features are not in WordPress 7.0 itself. They require installing the additional plugin. Similarly, the MCP Adapter — which allows AI agents to interact with WordPress via the Model Context Protocol — ships as its own separate plugin, not bundled in core. The WordPress project made a deliberate scoping decision to keep core lean.

What 42 Registered Abilities Look Like in the Real World

Abstract API documentation is one thing. A snapshot of a real production install is more instructive. We ran wp_get_abilities() on mxchat.ai itself — a live WordPress 7.0.2 site on PHP 8.2 running WooCommerce, Rank Math Pro, WPForms and roughly forty other plugins. It returns exactly 42 registered abilities. Here is how that breaks down by vendor, with the real registered names rather than a guess at what they might do:

A few things stand out from this data. First, the plugin ecosystem has adopted the Abilities API quickly — 39 of the 42 abilities come from third-party plugins, not core. Rank Math alone contributes nearly a third of the total. Second, and most critically for this discussion: WordPress core itself registers only 3 abilities, and they are deliberately conservative. All three are read-only information getters that expose site metadata to AI agents. They do not write, publish, or modify content autonomously. Core is not trying to run your site for you — it is opening the door for plugins and agents to do so in a structured, auditable way.

Third — and this is the finding that matters most if you are weighing up a chatbot — not one of the 42 abilities is conversational. Read the list end to end and every entry is a discrete admin operation: query orders, update a product, optimise an image, audit SEO, read email debug events. There is no ability that accepts a visitor's question, none that maintains a dialogue, and none that renders anything on the front end. That is not a shortfall in these particular plugins. It is what the API is for.

The MCP Adapter entries in that snapshot deserve a paragraph of their own, because they are the one genuine surprise in the list. The Model Context Protocol is the emerging standard for letting AI agents talk to external systems, and the adapter's job is to translate the abilities registry into MCP so an agent — Claude Code, Cursor, anything speaking the protocol — can discover and call what your site can do. Its three abilities are discover-abilities, get-ability-info and execute-ability: list what exists, describe one, run one.

That the adapter ships this way — vendored by plugins, published separately on WordPress.org, and pointedly not bundled in core — is an intentional signal about scope. WordPress is building the plumbing, not the agent.

The Critical Distinction: Admin-Side Plumbing vs Visitor-Facing Chat

Here is the sentence that should settle the debate for most site owners: the entire WordPress 7.0 AI layer is admin-side and developer-side infrastructure. It is designed so that AI agents and editors can operate your site more efficiently. It has no surface area that a website visitor ever touches.

This is not a gap that will be filled in a future minor release. It is a deliberate architectural boundary. The Abilities API executes discrete tasks on behalf of authenticated users and AI agents operating in the admin context. It was never designed to serve anonymous visitors arriving on your homepage.

What Core Does Not Ship

• No chat widget: There is no floating conversation bubble, no visitor-facing interface, no customer chat component of any kind in WordPress 7.0 or the canonical AI plugin.
• No knowledge base or retrieval layer: WordPress 7.0 does not index your posts, pages, WooCommerce products, or documentation into any vector store or semantic search system. There is no RAG (Retrieval-Augmented Generation) layer that an AI could query on a visitor's behalf.
• No conversation history: The Abilities API is stateless by design. It executes discrete tasks rather than maintaining a dialogue thread across multiple user turns. There is no session management, no stored conversation, no context that persists between requests.
• No lead capture: There are no form fields, no email collection flows, no CRM handoff mechanisms, and no escalation-to-human-agent pathways in the core AI layer.
• No visitor analytics: Core AI does not track what questions visitors are asking, what topics are unresolved, or where the conversation breaks down — because there is no conversation.

If you are evaluating chatbot plugins for your WordPress site, understanding this boundary is the most important thing you can take from this article. For a broader look at what modern chatbot plugins actually offer in 2026, see this guide to essential AI chatbot features to look for in 2026.

Core AI vs Chatbot Plugin: A Direct Capability Comparison

The table below maps eight capability dimensions across WordPress 7.0 core AI and a dedicated chatbot plugin. These are factual comparisons based on what the systems actually do, not marketing claims from either side.

The table makes the complementary nature of these tools clear. Core AI wins on developer extensibility and centralized credential management. Chatbot plugins win on everything that involves a visitor. There is no overlap in the capabilities that actually matter for customer-facing use cases.

For a detailed look at how specific chatbot plugins compare to each other on these dimensions, the Tidio vs MxChat comparison and the LiveChat vs MxChat breakdown both work through these criteria in depth.

Where a Chatbot Plugin Still Does the Work

If your goal is to answer visitor questions at scale — about your products, your return policy, your service pricing — you need a retrieval layer that can query your actual content and return accurate, grounded answers. WordPress 7.0 core provides none of this. The gap is not small; it is the entire visitor-facing surface of your website.

E-Commerce: WooCommerce Sites

WooCommerce is the sharpest illustration, because it registers 7 abilities and they look, at a glance, like exactly what a store chatbot would need: orders-query, order-update-status, order-add-note, products-query, product-create, product-update, product-delete. Read them again and the pattern is obvious — this is administrative CRUD, exposed so an authenticated agent can manage the store. product-delete is not a capability you hand to an anonymous visitor. A shopper asking "do you have this jacket in a medium?" needs grounded retrieval over your catalogue and a front-end surface to ask in; the Abilities API supplies neither, and the permission model behind it is the reason why. For a practical look at how this plays out in a specific vertical, the automotive chatbot guide for WordPress covers a comparable product-query use case in detail.

Support Deflection: A Measurable Business Outcome

Support deflection is where chatbot ROI becomes concrete, and it is worth measuring rather than assuming: take your tier-1 ticket volume, count how many arrive as questions your documentation already answers, and price that in hours. Whatever share a chatbot resolves before it reaches your inbox is the return, and it is a number you can actually check after a month. Core's AI layer optimises editor time — real value, different line item. It has no visibility into your support queue at all. If you are running a support operation and weighing automation, customer support automation for small business covers the decision framework in practical terms.

Lead Generation and Sales Qualification

Lead generation via conversational flows — qualifying a prospect, collecting contact details, routing to a sales rep — requires stateful conversation management, conditional branching, and CRM integration. These capabilities live entirely outside the scope of WordPress 7.0's AI architecture. The Abilities API has no concept of a conversation state machine. If converting website visitors into leads is a business objective, a chatbot plugin is not optional infrastructure — it is the mechanism. For context on how this connects to conversion outcomes, see how to increase sales conversion rate.

Industry-Specific Applications

Certain industries have visitor-facing chat requirements that go well beyond generic Q&A. Healthcare practices need HIPAA-aware chat flows for appointment booking and triage. Real estate agencies need chatbots that can surface listings, qualify buyer intent, and schedule viewings. Restaurants need after-hours ordering and reservation management. None of these use cases are touched by the WordPress 7.0 AI layer — they require purpose-built chatbot plugins with domain-specific knowledge and integrations.

How to Audit Your Own Site: A Decision Framework

Rather than a theoretical discussion, here is a concrete process for evaluating what you actually need after upgrading to WordPress 7.0.

Step 1: Run Your Abilities Snapshot

There is no Abilities browser in wp-admin — core registers the API, not a UI for it — so the fastest way to see what your plugins have already registered is WP-CLI:

That is the whole audit, and it takes about a minute. Expect surprises — most site owners have no idea Rank Math or WooCommerce have already registered a dozen operations against their site. Group what comes back by namespace and you have a complete picture of your admin-side AI surface area. If your install has no wp_get_abilities() function at all, you are on 6.x and none of this applies yet.

Step 2: Ask the Diagnostic Question

For every AI feature you are considering, ask one question: Is this feature facing my editors and agents, or my visitors?

• If the answer is editors and agents: evaluate whether a registered ability or the canonical AI plugin already covers it before installing another plugin. The ecosystem is moving fast, and the answer may already be in your abilities registry.
• If the answer is visitors: core AI is not the tool. Evaluate chatbot plugins based on your specific visitor-facing requirements.

Step 3: Evaluate Chatbot Plugins on Four Criteria

For visitor-facing requirements, evaluate chatbot plugins on these four dimensions:

1. RAG against your content types: Does the plugin support retrieval-augmented generation against your specific content — posts, WooCommerce products, documentation pages, custom post types? Generic AI without grounding in your content will hallucinate answers.
2. Data residency for conversation history: Where is conversation data stored? In your WordPress database, a third-party cloud, or a hybrid? This matters for GDPR compliance and data sovereignty.
3. CRM and lead capture integration: Does the plugin integrate with your existing CRM — HubSpot, Mailchimp, Salesforce — or does it require a separate workflow? Leads captured in a chatbot that don't flow into your CRM have limited value.
4. Pricing model at your traffic volume: Most chatbot plugins price per conversation, per seat, or per month. Run the numbers at your actual monthly visitor count, not the plan's headline figure.

Step 4: Avoid the Connectors Hub Trap

Do not assume that storing your OpenAI API key in the WordPress Connectors hub means your chatbot plugin will use it. Most current chatbot plugins manage their own API keys independently and do not yet integrate with WordPress core's Connectors hub. This may change as the ecosystem matures and plugin authors adopt the new architecture, but as of mid-2026, the two credential systems are separate. Check your specific plugin's documentation before assuming centralized credential management applies.

Step 5: Register Your Own Abilities (For Developers)

If you are a developer building on WordPress 7.0, registering your own abilities via wp_register_ability() is the correct way to expose your plugin's AI-powered admin tasks to the shared registry and the command palette. It is not the right architecture for building a visitor chat experience — the Abilities API has no session layer, no visitor identity model, and no front-end rendering system. Build admin automation with the Abilities API; build visitor chat with a purpose-built chatbot plugin or a custom front-end implementation.

Putting It Together: What Changes and What Doesn't

WordPress 7.0 'Armstrong' is a meaningful release. The Abilities API gives the ecosystem a shared, extensible infrastructure for AI-powered admin tasks. The Connectors hub is a genuine quality-of-life improvement for managing provider credentials. The command palette makes AI abilities accessible to editors who would never touch a developer console. These are real advances in how WordPress operates as a platform.

What does not change: the relationship between your website and the people visiting it. WordPress 7.0 has no chat widget, no retrieval layer, no conversation memory, no lead capture, and no visitor-facing AI surface of any kind. The 42 registered abilities on a typical production install are all oriented toward the people running the site, not the people visiting it.

For site owners who were using a chatbot plugin before May 2026 — to answer product questions, qualify leads, deflect support tickets, or engage visitors after hours — the case for that plugin is exactly as strong today as it was before Armstrong shipped. The two layers solve orthogonal problems and can coexist without conflict. Understanding the core benefits of chatbots for business helps clarify why the visitor-facing use case remains distinct from anything WordPress core now provides.

For developers, the Abilities API is the right place to invest time for admin automation work. For site owners evaluating their tooling stack, the honest answer is: check your abilities registry, identify your visitor-facing gaps, and choose your chatbot plugin based on what it actually does — not on assumptions about what WordPress 7.0 now covers.

One more thing changed for chatbot owners since this was written, and it has a hard date: from 2 August 2026 the EU AI Act requires your chatbot to tell visitors they are talking to an AI. It applies to non-EU site owners too.