The requested Ability is not registered

The three usual causes

1. The name is wrong. Ability names are exact, including the provider prefix. acme/update-post and acme/update_post are different strings.
2. The providing plugin is deactivated. Deactivating a plugin removes its Abilities from the registry. A workflow step naming one will now find nothing.
3. Version mismatch. The agent was written against a provider version that registered a name the installed version does not.

How to check

Search the Ability Explorer for the exact name from the activity record. If it is not there, it is not registered — the Explorer shows the live registry, not a cached list.

Then check whether the provider plugin is active. If it was deactivated deliberately, the fix is in the agent’s configuration, not here.

This is no longer noisy

Earlier behaviour looked Abilities up in a way that wrote a WordPress “doing it wrong” notice when they were not registered, so a workflow step naming a deactivated plugin’s Ability logged a notice on every run. That is fixed — an unregistered Ability is now simply refused and recorded.

Related guides

• AuthorityFind the Abilities registered on your site

  Use the Ability Explorer to browse by provider with filters for action, risk, category, exposure and source, and read the detail view before deciding anything.

• AuthorityUnderstand a blocked Ability

  Blocked, review required, no permission record, unregistered, or site mode — five outcomes that look identical to the agent and need different fixes.

• AuthorityWhat an Ability is, and what it is not

  An Ability is a registered, named action with a schema — the vocabulary of what an agent may ask for. It is not a permission.