The requested Ability is not registered
An unregistered Ability has no permission record, so it is refused before policy is reached. Nothing executed.
- Abilities & permissions
- 3 min read
The three usual causes
- The name is wrong. Ability names are exact, including the provider prefix.
acme/update-postandacme/update_postare different strings. - The providing plugin is deactivated. Deactivating a plugin removes its Abilities from the registry. A workflow step naming one will now find nothing.
- 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.
What happens to the request
An unregistered Ability is refused and recorded in the Activity trail, like any other refusal.
Abilities & permissions
Keep the boundary while you fix the problem.
A good fix restores intended behaviour without creating a second path around WordPress or the governed request lifecycle.
