Beyond Vanilla AI: How WordPress Is Becoming an Agent-Ready Platform

For the last few years, most conversations about AI in WordPress have centred on a familiar collection of features: generate a first draft, rewrite a paragraph, suggest a headline, translate an article, create alt text or produce an SEO description.

These tools have been useful. They have helped editorial and marketing teams remove repetitive work, move more quickly and become more comfortable with AI inside the content workflow.

But they are also what I would describe as “vanilla AI”.

The user provides a prompt, a model returns some text or an image, and a person decides what to do with the result. The AI sits beside the CMS as an assistant, but it does not truly understand the platform, its permissions, its content model, its business rules or the actions it is allowed to perform.

That is beginning to change.

With the WordPress Abilities API, the built-in AI Client and the WordPress MCP Adapter, WordPress is developing the foundations for a more sophisticated generation of AI-enabled digital experiences. Instead of simply asking AI to create an asset, organisations will be able to give authorised agents a structured and controlled way to discover what a WordPress platform can do, combine those capabilities into workflows and execute useful tasks.

For enterprise teams, this is a much bigger development than the arrival of another content-generation plugin. It begins to move WordPress from being a CMS with AI features to being a platform on which AI-enabled products, workflows and operating models can be built.

The limitations of vanilla AI

The first wave of AI tools generally performs isolated tasks one at a time. A plugin may generate an article, summarise a page or recommend keywords, but it usually operates within its own interface and according to its own integration with a particular model.

That creates several limitations.

First, the AI often has very little reliable context. It may not understand the organisation’s taxonomy, design system, editorial guidelines, approved claims, product catalogue, regional structure or publishing permissions. A larger prompt can provide some of that context, but prompts alone are a fragile way to encode an enterprise operating model.

Second, the output is usually disconnected from the next action. Creating copy is not the same as creating a compliant landing page, selecting the right components, assigning the correct taxonomy, configuring analytics, routing the page for legal approval and scheduling it for a specific market.

Third, many AI plugins create another technology silo. Each may have its own provider, settings, credentials, permissions and usage logs. This increases operational complexity and makes governance harder, particularly across a large WordPress Multisite estate.

Finally, a language model should not be given unrestricted access to a production CMS. Models are probabilistic. Enterprise publishing, security and compliance require deterministic controls around what can be read, changed, approved and released.

The opportunity is therefore not to let an AI model “run WordPress”. It is to expose carefully designed WordPress functions to AI through a governed execution layer.

That is where the Abilities API becomes important.

The Abilities API turns WordPress functionality into reusable building blocks

Introduced in WordPress 6.9 and expanded through subsequent releases, the Abilities API provides a standard way for WordPress Core, plugins and themes to describe functionality in a machine-readable format. An ability is a self-contained unit of work with a name, description, defined inputs and outputs, a permission check and the execution logic required to complete the task. The official WordPress documentation describes it as a unified, discoverable and security-focused way to expose what WordPress can do.

An enterprise platform could, for example, register abilities such as:

• create a draft campaign page from an approved pattern;
• retrieve content by market, product or audience segment;
• validate a page against brand and accessibility requirements;
• translate approved content while preserving protected terminology;
• create a new site within a WordPress Multisite network;
• apply a regional configuration and design-token set;
• submit a page to an editorial or legal approval workflow;
• recommend related content using first-party behavioural data; or
• generate a performance, accessibility or content-governance report.

Each ability has a defined contract. The caller knows what information it must provide, what result it should receive and whether the current user is permitted to execute it. WordPress can validate inputs and outputs, run the relevant permission callback and expose selected abilities through PHP, JavaScript or REST interfaces.

This standardisation matters because it separates the business action from the interface used to request it.

A capability such as “create a regional campaign site” might be initiated from a conventional admin screen, a command palette, an internal marketing portal, a workflow automation or an AI conversation. The underlying rules remain the same. The organisation does not need to rebuild the action for every new AI model or user interface.

Abilities can also be composed. One ability can retrieve and analyse an image, another can generate structured copy, and an orchestrating ability can use both results to create a draft post. WordPress’ own developer example demonstrates this composition model and compares abilities to reusable building blocks.

That is the point at which AI moves beyond a clever button. Small, governed capabilities can be assembled into larger, repeatable business processes.

WordPress MCP gives AI agents a standard way to use those abilities

The Abilities API tells other systems what WordPress can do. The WordPress MCP Adapter provides a bridge through which compatible AI agents can discover and use selected abilities.

MCP stands for Model Context Protocol. It is an open protocol that gives AI applications a consistent way to connect to tools and data. The official WordPress MCP Adapter translates registered WordPress abilities into MCP primitives: tools that can perform actions, resources that provide context and prompts that help guide repeatable workflows.

In simple terms, the Abilities API is the catalogue of approved capabilities; MCP makes that catalogue understandable and accessible to an AI agent.

An authorised user could ask:

Create a draft site for our new Spanish business unit using the corporate blueprint, apply the Spanish design settings, generate the initial page structure from the approved brief and send the result to the regional marketing lead for review.

The model does not need unrestricted database access, nor should it invent its own way of completing the task. It can identify the relevant abilities, gather any missing inputs, propose a plan and call the permitted tools in sequence.

This is a fundamental change in the relationship between AI and the CMS. The AI is no longer limited to generating content that somebody must manually transfer into WordPress. It can become an orchestration layer across defined CMS capabilities.

It is equally important to be precise about what has been introduced. The MCP Adapter is an official WordPress AI Building Blocks package and can be installed as a plugin; it is not permissionless AI administration built into every WordPress site. WordPress is deliberately creating infrastructure and extension points, leaving organisations and plugin developers to decide which experiences, providers and abilities should be enabled.

That architectural separation is a strength. Models and protocols will continue to change. Business capabilities such as “create a draft”, “check accessibility” or “provision a site” are more durable. By defining those actions once and connecting them through adapters, enterprises can innovate without tightly coupling their operating model to one AI vendor.

From prompt to governed WordPress Multisite provisioning

At Multidots, we are already beginning to explore what this more advanced model can look like in practice.

One area of innovation is the use of prompt-driven tools to build new sites within a WordPress Multisite network on the fly. For a global enterprise, publisher, franchise group or multi-brand organisation, launching a new site can involve a long chain of repetitive tasks: selecting a blueprint, creating the site, applying brand settings, generating navigation, configuring roles, adding standard pages, connecting analytics, setting language and regional options, and preparing the first content for review.

Much of that work is rules-based. It should not require a developer to repeat the same setup manually every time.

Imagine an authorised platform owner entering a structured request such as:

Create a new campaign site for Brand X in Germany. Use the product-launch blueprint, inherit the approved global component library, apply German localisation settings, connect the standard analytics configuration and prepare draft pages for the launch, product, sustainability, media and contact sections.

A well-designed AI workflow could interpret that request, identify the appropriate blueprint and convert the intent into a proposed provisioning plan. Behind the prompt, deterministic WordPress abilities would perform the actual operations: validate the request, create the site, apply the approved configuration, assemble pages from registered patterns, assign roles, generate draft content, run quality checks and notify the appropriate reviewer.

The distinction between interpretation and execution is essential.

The language model is good at understanding intent, resolving ambiguity and assembling a plan. WordPress abilities are responsible for completing defined actions within explicit permissions. Human approval can be required before costly, sensitive or irreversible steps. The entire process can be logged and, where appropriate, rolled back.

This approach could reduce the time required to launch a new regional or campaign site from weeks to hours, while improving consistency across the network. More importantly, it allows a central digital team to encode its governance model into the platform itself. Brand rules, accessibility standards, mandatory integrations and publishing workflows become part of the provisioning process rather than items on a checklist that can be missed.

Hyper-personalisation becomes an operating capability, not just a front-end feature

The same building-block approach can support a much more sophisticated form of personalisation.

Many personalisation projects begin with a collection of front-end rules: visitors from one location see a particular banner; returning users see a different call to action; readers interested in one topic receive more recommendations from the same category.

Those rules can produce value, but genuine hyper-personalisation requires more than swapping a hero image. It requires content to be structured, audiences to be understood, decisions to be made in real time and outcomes to be measured. It must also respect consent, privacy, editorial policy, caching and performance.

In an ability-led architecture, the personalisation process can be divided into controlled services:

• retrieve the consent and audience context available for the current interaction;
• identify eligible content, offers or components;
• exclude content that is unsuitable for the user, market or regulatory context;
• rank the remaining options against a defined objective;
• assemble or select the appropriate experience;
• record the decision and outcome for measurement; and
• return aggregate insight to improve future decisions.

AI can help interpret behaviour, recognise patterns and select the next best experience, while WordPress retains control of the content, components, permissions and publishing state.

For publishers, this might mean homepages, article recommendations, newsletter prompts or propensity-based subscription journeys that adapt to a reader’s interests and engagement. For an enterprise brand, it could mean industry-specific case studies, regionally relevant product information or different journeys for prospects, customers, partners and investors. For a large Multisite network, the experience could reflect both global brand strategy and local market context without duplicating the entire content operation.

Multidots is starting to innovate in this space by connecting AI prompt tools, reusable WordPress components, Multisite governance and hyper-personalisation. The aim is not to generate an uncontrolled version of every page for every visitor. It is to make approved content and functionality more responsive to context, while keeping the organisation’s design system and governance intact.

The enterprise architecture behind agent-ready WordPress

To make these ideas reliable at scale, organisations need to think beyond the model and design the surrounding operating architecture.

The five layers of an agent-ready WordPress architecture.

1. An intent layer

This is where a human or another system expresses the desired outcome. It could be a conversational prompt, a form, a ticket, an event in a CRM or a scheduled workflow.

The intent layer should gather missing details and convert an open-ended request into a structured plan. It should not be allowed to bypass the organisation’s rules.

2. A capability layer

The Abilities API provides the contract for what the platform can do. Good abilities should be narrow, clearly described, independently testable and protected by the minimum necessary permission.

This layer turns years of custom WordPress engineering and business knowledge into reusable platform capabilities.

3. A connection and orchestration layer

MCP, REST and the WordPress JavaScript APIs provide different routes through which approved clients can discover and execute abilities. The WordPress AI Client, built into WordPress 7.0, also gives plugins a provider-agnostic way to call supported AI models rather than embedding a separate vendor integration into every feature.

The organisation can therefore choose the right model for a task while keeping the underlying WordPress capability stable.

4. A governance layer

Enterprise AI requires identity, authentication, authorisation, approval gates, audit logs, usage policies and data controls. An agent should operate as a known user or service identity and inherit the same principle of least privilege that applies to human users.

WordPress 7.1 has continued to mature this model, including a unified metadata flag for abilities intended to be exposed to external clients, while preserving channel-specific controls and permission callbacks.

5. An observability and learning layer

Teams need to know which abilities were called, by whom, with what inputs, at what cost and with what outcome. They also need to distinguish between a model suggestion and a completed system action.

This data supports security review, performance optimisation, cost management and continuous improvement. It is also vital when an organisation needs to explain why a particular experience, recommendation or publishing action occurred.

Safety must be designed in from the beginning

Agent-ready does not mean agent-controlled.

The official WordPress guidance recommends starting with non-destructive, read-only abilities, using dedicated users with restricted permissions, applying the minimum WordPress capability to every ability and monitoring usage. It specifically warns against exposing powerful abilities to unaudited AI clients.

For an enterprise implementation, we would extend those principles further:

• separate read, draft, approve and publish permissions;
• require human approval for high-impact actions;
• use staging or preview environments for generated experiences;
• maintain an immutable audit trail of agent activity;
• validate all model output against schemas and business rules;
• treat retrieved content as data, not as instructions, to reduce prompt-injection risk;
• redact sensitive data before it reaches a model;
• set limits for token usage, execution time and the number of actions in a workflow;
• test fallbacks for unavailable models or integrations; and
• define rollback and incident-response processes before enabling production writes.

This is not a reason to delay experimentation. It is a reason to experiment properly.

Where enterprises should start

The most effective first project is rarely “add an AI chatbot to the website”. It is usually a constrained internal workflow with clear inputs, measurable value and low operational risk.

Good candidates include:

• content inventory and quality reporting;
• broken-link, accessibility or SEO analysis;
• recommending taxonomy and internal links for an editor to approve;
• assembling campaign pages as drafts from approved components;
• translating approved content into a review workflow;
• preparing a new Multisite site from an established blueprint; or
• recommending personalised content without automatically publishing new material.

Start by mapping the workflow as it operates today. Identify which decisions genuinely require human judgement and which steps are deterministic. Turn the deterministic steps into secure, reusable abilities. Introduce AI where it adds value through interpretation, classification, summarisation or orchestration.

Then measure the result. Did the workflow reduce launch time, improve consistency, increase conversion or remove repetitive work? Did it create new review overhead? What did each completed process cost? Where did the model require correction?

This creates an evidence base for moving from a pilot to a platform capability.

Why open source matters in the agentic era

There is a broader strategic point here.

In a closed CMS, the platform vendor largely determines which models, agents, connectors and automation patterns are available. AI may be packaged as a premium feature, limited by credits or designed primarily to increase dependency on the vendor’s own ecosystem.

WordPress is taking a different route. The Abilities API defines an open and extensible way to describe functionality. The AI Client provides a provider-agnostic model interface. The MCP Adapter connects those capabilities to an open protocol. Plugins and enterprise development teams can build on the same foundations rather than waiting for a single CMS vendor to define every use case.

This does not automatically make every WordPress AI implementation good. Open systems still require strong architecture, engineering, security and governance. But they give organisations more control over how their capabilities are designed, where their data flows, which providers they use and how quickly they can innovate.

That flexibility could become one of WordPress’ most important enterprise advantages in the next phase of AI.

Moving from AI features to AI-enabled operations

Vanilla AI tools will not disappear. Drafting, translation, metadata generation, image support and editorial assistance will remain valuable parts of the WordPress experience.

But they are no longer the limit of the opportunity.

The next generation of WordPress AI will be built from governed capabilities that can be discovered, combined and executed across real business workflows. It will help enterprises launch new sites, manage large content estates, coordinate teams, adapt experiences to audiences and connect WordPress more intelligently to the rest of their technology stack.

Multidots is already taking steps in that direction through prompt-led Multisite creation and hyper-personalisation initiatives. These are early examples of a much larger shift: from using AI to generate content inside WordPress to using AI to help operate and evolve WordPress as an enterprise digital platform.

The organisations that benefit most will not be those that install the largest number of AI plugins. They will be those that identify their most valuable capabilities, encode them safely, connect them through open standards and build the governance needed to use them with confidence.

The future of AI in WordPress is not another button labelled “Generate”.

It is a platform that understands what it can do—and gives authorised people and agents a safe, structured way to do it.

Thinking about what an agent-ready WordPress platform would look like for your organisation? Talk to our team about mapping your workflows into governed, reusable abilities.