WordPress 7.0 AI infrastructure and the end of glue code

The way we have been building AI features needs to change. For the last couple of years, integrating an LLM into a site meant hardcoding an OpenAI key into a custom options page, writing a bespoke wrapper for that provider’s API, and hoping nobody deprecated an endpoint overnight. Wanting to switch to Anthropic meant starting over. The upcoming WordPress 7.0 AI infrastructure replaces that with a standard foundation.

Rather than every plugin author solving the same problem again, core is moving to a provider-agnostic architecture. It changes how WordPress handles external intelligence: there is now a shared layer where AI services and site capabilities can talk to each other, instead of dozens of brittle one-off bridges.

The Abilities API: a registry of what your site can do

The first piece of the WordPress 7.0 AI infrastructure is the Abilities API, a registry of what your site can actually do. Getting an AI to update a WooCommerce stock level used to mean writing the logic for that one request yourself. Plugins can now register abilities that external tools discover on their own.

An ability is more than a function. It declares its inputs, its return type and, most importantly, the permissions a caller needs. Whether you are doing serious AI integration or a small automation, there is one standard way to ask a site what it can do, over REST endpoints or the Model Context Protocol (MCP).

<?php
/**
 * Example: Registering a custom ability to optimize product descriptions.
 */
function bbioon_register_product_optimizer_ability() {
    if ( ! function_exists( 'wp_register_ability' ) ) {
        return;
    }

    wp_register_ability( 'bbioon/optimize-product', [
        'description' => __( 'Optimizes WooCommerce product descriptions for SEO.', 'bbioon' ),
        'parameters'  => [
            'product_id' => [
                'type'     => 'integer',
                'required' => true,
            ],
        ],
        'callback'    => 'bbioon_handle_product_optimization',
        'capabilities' => 'edit_products',
    ] );
}
add_action( 'init', 'bbioon_register_product_optimizer_ability' );

The WordPress AI client: decoupling the provider

The second piece is the AI Client. I have worked on sites running four different plugins, each wanting its own OpenAI API key, which is a performance problem and an administrative one at the same time. The AI Client gives you one PHP interface for talking to any model, so your code stays the same whether Claude, GPT-4 or Gemini is behind it.

The Connectors API sits alongside the client and keeps external service credentials in one central Connectors screen. When a client decides to move from OpenAI to a self-hosted Llama instance, that is a settings change, and no plugin logic needs refactoring. I put this in the context of the wider core roadmap in my notes on the WordPress 7.0 AI Roadmap.

What the MCP adapter connects

The Abilities API covers what a site can do and the AI Client covers how to call a model. The MCP Adapter is the bridge between them and the outside world. Model Context Protocol (MCP) is an open standard that lets AI assistants such as Claude or ChatGPT see and use your site’s tools directly, which is what allows an AI to act as a site administrator under your supervision.

Ask an assistant to find all products with low stock and draft a restock report. That used to be a chain of API calls somebody had to write by hand. Now the assistant sees the abilities WooCommerce registered and calls them. That level of interoperability has not existed in this ecosystem before. The technical specifics of the client are covered on Rich Tabor’s blog.

If the 7.0 AI work is eating your dev hours, I can take it on. I have been working with WordPress since the 4.x days.

Building on the shared layer

Building AI features in isolation has stopped making sense. Registering what your plugin does as abilities and calling models through the centralized AI Client leaves one less private integration for someone to maintain in two years, and a site that holds up when a provider changes its API. The foundation is here now, so there is not much reason to keep writing glue code around it.

The official announcement, with more examples, is on the WordPress.com blog.

author avatar
Ahmad Wael
I'm a WordPress and WooCommerce developer with 15+ years of experience building custom e-commerce solutions and plugins. I specialize in PHP development, following WordPress coding standards to deliver clean, maintainable code. Currently, I'm exploring AI and e-commerce by building multi-agent systems and SaaS products that integrate technologies like Google Gemini API with WordPress platforms, approaching every project with a commitment to performance, security, and exceptional user experience.