I had a client recently who had been experimenting with AI on their WordPress site, and the early results were genuinely good. Then it scaled. More features, more providers, and their admin area turned into a pile of settings screens, one per plugin, each asking for an API key they had already entered somewhere else. Configuration became the job. That is a problem you fix with a system, not with another band-aid.
My first thought, and looking back it was naive, was to build a custom settings page for the integrations they already had. One table, a few text fields, done. It would have worked that week. But every new AI tool and every new provider would have needed its own custom fix, and shipping that is shipping tech debt. They needed a framework, not a one-off.
Standardizing WordPress AI abilities and settings
This is not a problem unique to one agency. Core is working out a structured way to handle AI capabilities right now, and the Core AI contributor check-ins are where it gets argued through. The summary from October 8th, 2025 on make.wordpress.org/ai lands on the same pain points I keep running into on client sites.
The item I care about most is what they call a "grouping mechanism (like ‘categories’)" for the Abilities API. If every AI tool registers itself with no classification, you end up with thousands of abilities and no way to find or filter them. Requiring a category from the first release is the right call, because organization is much harder to retrofit once people are shipping against the API.
They are also settling which arguments go where. Root-level arguments hold what the AI action needs in order to run, such as the input and output schemas. A ‘meta’ object takes the descriptive, optional and experimental parts. Drawing that line gives you an API you can predict, and it keeps calls from carrying data nobody asked for. It also leaves room to extend the thing later without breaking what already works.
<?php
/**
* Registers a new AI ability with categories and structured arguments.
*
* @param array $ability_args Arguments for the AI ability.
* @return bool True on success, false on failure.
*/
function bbioon_register_ai_ability( $ability_args ) {
$defaults = array(
'id' => '',
'name' => '',
'description' => '',
'category' => 'general', // Crucial grouping mechanism.
'schema' => array(), // Root-level: required for execution.
'callback' => null,
'meta' => array(), // Optional: descriptive, non-essential.
);
$args = wp_parse_args( $ability_args, $defaults );
if ( empty( $args['id'] ) || empty( $args['name'] ) ) {
return false; // Man, gotta have an ID and name.
}
// In a real scenario, this would register with a global AI Abilities API.
// For now, let's just log it.
error_log( 'Registered AI Ability: ' . print_r( $args, true ) );
return true;
}
// Example usage:
bbioon_register_ai_ability( array(
'id' => 'bbioon_image_generator',
'name' => 'Image Generation',
'description' => 'Generates images based on text prompts.',
'category' => 'content_creation',
'schema' => array(
'input' => '{ "type": "string", "description": "Text prompt for image" }',
'output' => '{ "type": "string", "description": "URL of generated image" }',
),
'callback' => 'bbioon_generate_image_callback',
'meta' => array(
'show_in_rest' => true,
'version' => '1.0',
),
) );
Then there is the settings experience, which is where my client actually got hurt. Scattered API credentials are a recognized "highest friction point" for adoption. The fix under discussion is a central provider settings screen: one place to enter your OpenAI, Gemini or other credentials. Individual AI features then read that configuration, or offer a gentler route such as a modal for adding a provider, instead of throwing the user out to a full page redirect. Developers can live with settings scattered across five screens. Site owners mostly cannot, and they are the ones who decide whether AI on the site gets used.
Making AI in WordPress usable
All of this is foundation work rather than features: clear argument definitions, a grouping mechanism such as categories, and settings that do not send people hunting through five plugin screens. Getting that in place before the ecosystem fills up is the difference between AI in WordPress staying manageable and turning into another pile of one-off integrations.
This stuff gets complicated fast. If you are tired of debugging someone else’s mess and just want your site to work, drop my team a line. We have probably seen it before.
