I’ve spent the last 14 years watching WordPress evolve from a simple blogging tool into a massive application framework. Usually, when “AI” gets mentioned in our ecosystem, it’s a bloated plugin trying to sell you a subscription. However, the latest batch of WordPress AI Experiments coming out of the Core AI team is different. This isn’t just about generating text; it’s about the underlying architecture of how WordPress interacts with LLMs.
The team recently dropped a Call for Testing for several new concepts in the AI Experiments plugin. If you’re a developer or a site owner who cares about performance and standardizing how we use these tools, you need to be paying attention. We are talking about everything from Model Context Protocol (MCP) to native AI request logging.
Why These WordPress AI Experiments Matter
Frankly, the most exciting part of these experiments isn’t the “User-Facing” stuff like type-ahead suggestions. While helpful, those are UX sugar. The real meat is in the developer-focused tools. Specifically, the integration of the Model Context Protocol (MCP) and the standardized AI Building Blocks.
Furthermore, the Markdown Feeds experiment is a masterstroke for decoupling content. By allowing a post to be requested as text/markdown, WordPress finally starts playing nice with external AI agents and static site generators without needing a complex REST API handshake every single time.
The Developer Experience: MCP and Request Logging
If you’ve ever tried to debug a “race condition” in an AI-powered block, you know it’s a nightmare. That’s why the AI Request Logging experiment is a game-changer. It tracks provider data, token counts, and—most importantly—cost estimates. In a production environment, you cannot ship AI features without this level of visibility.
The MCP integration allows WordPress to act as a “Server” for AI assistants like Claude Desktop or Cursor. Imagine your IDE having direct, secure access to your site’s abilities. This is the “Abilities API” in action, and it’s how we move away from messy, hard-coded prompts to structured, tool-based interactions.
How to Test the Extended Providers
One of the experiments expands the set of providers to include Groq, DeepSeek, and others. This uses the WP AI Client SDK, which I previously discussed in my post on standardizing generative AI. The goal is to make the model swappable via filters, rather than being locked into one vendor.
<?php
/**
* Conceptual example: Filtering AI Provider Options
* This reflects the logic being explored in the Extended Providers experiment.
*/
function bbioon_customize_ai_providers( $providers ) {
// Add a local Ollama instance for testing privacy-focused workflows
$providers['local-ollama'] = [
'label' => 'Local Ollama',
'endpoint' => 'http://localhost:11434/v1',
'type' => 'openai-compatible',
];
return $providers;
}
add_filter( 'wp_ai_providers', 'bbioon_customize_ai_providers' );
The “War Story”: When Unlogged AI Requests Go Rogue
I once had a client who integrated a basic “AI content improver” without any request logging or transients. Consequently, a bot crawled their site, triggered the AI hook on every page load, and ran up a $400 API bill in four hours. This is why WordPress AI Experiments like the Request Logging and Purge Logs features aren’t just “nice to have”—they are technical necessities for anyone building at scale.
Look, if this WordPress AI Experiments stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days and I know where the bottlenecks are.
Call to Action: Get Involved
You can test these experiments right now using WordPress Playground. You don’t need to spin up a local staging site or mess with your production database. Go to the WordPress AI GitHub repository, grab the plugin, and leave feedback on the PRs. The core team is actually listening—especially to those of us who deal with the mess of real-world client sites every day.
