Plugin Availability
Understand plugin registration state and runtime availability
Plugin Availability
There are two facts that are easy to confuse:
- registered
available
Registered
This means:
- whether the plugin is currently registered on the Agent
In snapshots, the legacy enabled field means "registered", not a project config switch.
If plugin lifecycle startup fails, the plugin state can become error for diagnostics. Ordinary action business failures do not mark the whole plugin as error; for example, a failed skill.lookup returns that action failure while the skill plugin remains callable.
available
This means:
- whether the plugin can actually work right now in the current context
Think of it as runtime readiness or health.
A plugin can absolutely be:
- registered
- but
available = false
For example:
- a provider is not installed yet
- Python dependencies are missing
- a required model was not downloaded
Why two layers exist
Because "the Agent registered it" and "the dependency chain is actually ready" are different facts.
That split lets UI describe:
- registration state
- health state
Static catalog vs runtime availability
Static catalog
The control-plane catalog mainly answers:
- does this plugin exist
- can an Agent register it
It does not always have a full runtime context to perform deep checks.
Runtime availability
Runtime availability is closer to:
- can this plugin really work right now
It can combine:
- current config
- dependency inspection
- plugin-specific availability logic
How to think about chat authorization now
Chat authorization is now a built-in runtime capability of ChatPlugin; it is no longer registered as a separate plugin.
That means it no longer appears as its own catalog entry. Whether chat authorization exists depends on whether the current agent has ChatPlugin registered.
Safest mental model
Remember it as:
- registration is the switch
availableis the health