New Experiment: Abilities toggle

[jeffpaul]

What problem does this address?

As we're already adding new abilities (e.g. #691, #774) and considering abilities outside of just read capabilities (e.g. #764), I would like to see us wrap these at least within a single "Ability APIs" sort of Admin Experiment. Read-only abilities are one thing to have automatically exposed on sites, but ones that could be destructive feel like it should be purposely enabled by a site owner before those are available.

What is your proposed solution?

For now, let's at least wrap available Ability APIs from the AI plugin in an experiment so that they're purposely enabled for usage/testing.

Why is this important to you?

There's a potential future state where we have so many abilities across CRUD operations that it would be not as easy to just "enable all abilities" sort of a settings toggle and perhaps then consider updating the Abilities Explorer to be a broader experiment where within that you can enable individual abilities or types of abilities or whatever.

I have searched existing issues and this is not a duplicate.

• Yes

[hbhalodia]

Hi @jeffpaul, I wanted to understand on this more.

I dug into how abilities are currently registered and gated, and I want to confirm the scope before deep diving in it.

Experiment/feature-backed abilities are already gated.
Every ai/<ability> that belongs to an experiment or feature is registered inside that feature's register() method, which the Loader only calls when the feature is enabled (global toggle and the individual feature toggle):

ai/includes/Features/Loader.php

Lines 193 to 201 in 8c3606a

	foreach ( $this->registry->get_all_features() as $feature ) {
	// Skip if feature is disabled.
	if ( ! $feature->is_enabled() ) {
	continue;
	}
	// Register the feature.
	$feature->register();
	}

If the toggle is off, register() is never called, the wp_abilities_api_init listener is never attached, and the ability is never registered - so it's absent everywhere (REST, MCP, Abilities Explorer, execution). These already satisfy "purposely enabled," e.g. ai/summarization, ai/meta-description, ai/alt-text-generation, ai/comment-analysis, ai/suggest-reply, ai/image-generation, etc.

The abilities that are not gated are the standalone ones registered directly in Main:

ai/includes/Main.php

Lines 136 to 144 in 8c3606a

	// Register our post-related WordPress Abilities.
	( new Posts() )->register();
	// Expose curated core objects to the Abilities API, then register the
	// core abilities (overriding any core-provided copies).
	( new Show_In_Abilities() )->register();
	( new Settings_Ability() )->init();
	( new Users_Ability() )->init();
	( new Content_Ability() )->init();

These register unconditionally on every request, outside the Loader's enablement loop:

• core/read-content
• core/read-settings
• core/read-users
• ai/get-post-details
• ai/get-post-terms

(plus the Show_In_Abilities polyfill that backs core/read-content).

Unlike the ones above, these are pure Ability APIs with no experiment/feature attached, so there's currently no way for a site owner to turn them off - and this is the set that's expected to grow into CRUD/write operations.

So the question I want to confirm: is the intent to introduce a toggle/experiment specifically for these standalone abilities — so they can be purposely enabled/disabled the same way the feature-backed ones already are — given they have no experiment behind them today?

If so, I'd propose wrapping exactly this group in a new "Abilities" experiment and moving their registration behind the same Loader gate, leaving the already-gated feature abilities untouched to avoid double-gating.

Does that match what you had in mind, or it's something else here?

Thanks,

[jeffpaul]

So the question I want to confirm: is the intent to introduce a toggle/experiment specifically for these standalone abilities — so they can be purposely enabled/disabled the same way the feature-backed ones already are — given they have no experiment behind them today?

If so, I'd propose wrapping exactly this group in a new "Abilities" experiment and moving their registration behind the same Loader gate, leaving the already-gated feature abilities untouched to avoid double-gating.

Yes, I'm specifically interested in these standalone abilities. As you've noted the other experiment/feature-related abilities are tied to its overall experiment/feature being enabled.

And yes, you're proposal is what I had in mind. The one thing I was considering was expanding the Abilities Explorer experiment to allow for enabling these other abilities within that experiment's UI (versus adding another experiment toggle on the AI settings page). Any thoughts on your end between these two options?

[hbhalodia]

The one thing I was considering was expanding the Abilities Explorer experiment to allow for enabling these other abilities within that experiment's UI

I guess this would be good. This would be something like, nested toggle for those ungated abilities. If the user want they can enable those ability and once enabled, it would be visible on Abilities Explorer page.

versus adding another experiment toggle on the AI settings page

I am not thinking to add it how the Experiments are gated because, it would then fall under Editor Experiments section, which is not correct IMO.

I would work on draft implementation on what discussed so far, so that we can see and re-iterate over it to refine.

Thanks,

[hbhalodia]

Hi @jeffpaul, This is what I have implemented as a draft.

Screen.Recording.2026-07-17.at.3.47.54.PM.mov

Let me know if that is what we needed, Will raise the draft PR for implementation.

[jeffpaul]

No strong feelings here, besides the fact that I'm trying to minimize additional settings toggles beyond the initial enabling of experiments. If there are additional toggles, those should be hidden behind the developer tools option that exposes those. Alternatively considering if those could be something exposes instead within Abilities Explorer is something I'd appreciate others' input on. cc: @dkotter

[dkotter]

If there are additional toggles, those should be hidden behind the developer tools option that exposes those. Alternatively considering if those could be something exposes instead within Abilities Explorer is something I'd appreciate others' input on. cc: @dkotter

Not sure I love either approach here. My concern with both is they require you to first enable the Abilities Explorer experiment. Is that going to be clear to users that they need to take that step to gain access to these Abilities?

If we put these as individual toggles on the settings page, as Jeff mentions, we'd likely want to hide those in the "Advanced settings" mode, which is even one more step someone has to take to gain access to these.

If we put these on the Abilities Explorer page, a user needs to go to that page and turn things on there, which again, is one (or more) steps they need to figure out.

I would suggest one of the following:

1. If we put these as part of the Abilities Explorer experiment, let's default to having these extra Abilities available immediately. And then have toggles to turn off the Abilities within "Advanced settings". This way a user only has to toggle on the experiment to gain access to things instead of having to toggle on the experiment, toggle on "Advanced settings" and then toggle on each individual Ability
2. Instead of putting these within Abilities Explorer, create a new experiment that wraps all of these (which if I'm reading correctly, that seems like the original request here). A user then toggles on that experiment and gains access to all custom Abilities without having to toggle anything else on

[jeffpaul]

Instead of putting these within Abilities Explorer, create a new experiment that wraps all of these (which if I'm reading correctly, that seems like the original request here). A user then toggles on that experiment and gains access to all custom Abilities without having to toggle anything else on

In general I like less settings/options, but in this case I think the right thing is a new Experiment to enable certain sets of (or all custom?) abilities.