Why WordPress core is starting to treat AI like the database

I remember working on a huge product catalog for a client about three years ago. Around 50,000 SKUs, and the search was a total nightmare. The client was frustrated because customers looking for “crimson sweaters” got nothing when the product was tagged “red.” I did what any senior dev would have done at the time and went deep into the SQL weeds: complex join queries and a large synonym table. It killed performance. My next idea was to cache the results in a transient, and that held up for a while. Then the cache cleared and the first visitor got a five-second hang.

Eventually I worked out that I was forcing a relational database to do something it was never built for. What I was missing was the intent behind the data. That is why the recent discussion on Make WordPress Core about AI as a WordPress fundamental lands so well with me. We are heading toward a world where AI in WordPress is as foundational as the database itself, rather than a fancy plugin feature.

Why AI is becoming the new database standard

Think about it. We take the database for granted. You do not check whether $wpdb exists before you query a post. You assume the data persistence layer is there. The AI team’s proposal is to treat AI models the same way. If a host provides the model, developers can stop worrying about API keys and start building “Abilities” instead. That is a big change in how we work. Rather than writing a custom wrapper for every LLM, we get a standardized API. It follows the same logic as AI for WordPress hosts is becoming the new standard.

When I first started playing with the “Abilities API,” I assumed it was another way to call a chatbot. It isn’t. The point is making your site’s own functions discoverable. Here is a quick example of registering a custom ability for a store, which exposes one internal function to whatever AI model is running on the site.

/**
 * Registering a custom ability for product stock checks.
 * Prefixing with 'bbioon' as per our internal standard.
 */
function bbioon_register_stock_check_ability() {
    if ( ! function_exists( 'wp_register_ai_ability' ) ) {
        return;
    }

    wp_register_ai_ability(
        'bbioon/check-stock',
        array(
            'description' => 'Checks the current stock levels for a specific product SKU.',
            'parameters'  => array(
                'sku' => array(
                    'type'        => 'string',
                    'description' => 'The unique product SKU.',
                    'required'    => true,
                ),
            ),
            'callback'    => 'bbioon_handle_stock_query',
        )
    );
}
add_action( 'init', 'bbioon_register_stock_check_ability' );

function bbioon_handle_stock_query( $args ) {
    $product_id = wc_get_product_id_by_sku( $args['sku'] );
    if ( ! $product_id ) {
        return 'Product not found.';
    }
    $product = wc_get_product( $product_id );
    return 'The stock level for ' . $product->get_name() . ' is ' . $product->get_stock_quantity();
}

Standardization over fragmentation

The useful part is that once this is in core, we stop building silos. Every developer has tried to bridge three different AI plugins that all want to solve the same problem their own way, and it is a mess every time. With standardized building blocks, a plugin from one dev can talk to another dev’s theme through the AI layer. I have made this argument before in writing about why standardized AI features matter for the ecosystem. It heads off the wild west of conflicting endpoints.

This is more than hype. When the Workflows API lands, your WordPress site will interpret the data it stores rather than only holding it. Ask for “warm clothes” and it should surface the “crimson sweater” without anyone writing a line of SQL synonym logic.

What to do about it now

The takeaway is to start thinking in “Abilities.” AI is not a chat box in the corner of the screen. It is a way to expose your plugin’s functionality to a smarter processing layer. If you are building a custom WooCommerce setup or a complex directory, look at how your data can be interpreted rather than just queried. Running the thought experiment of WordPress without a database shows how much we already lean on it. In five years, I expect we will say the same about AI.

This stuff gets complicated fast. If you are tired of debugging someone else’s mess and just want your site to work with these new standards, drop my team a line. We have probably seen it before.

Are you ready to stop fighting with complex queries and start using the AI layer, or are you waiting for core to make the first move?

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.