Plugins & providers

Plugins vs. providers — what each is

• Plugin — A governed extension. Adds an integration, a UI surface, a workflow handler, a memory adapter, a tool. Lives inside your exocorp’s operator portal with its own scope (organization, team, or agent). Concrete examples: a Slack integration, a calendar connector, a CRM adapter, a custom dashboard.
• Provider — The model behind an agent. Anthropic, OpenAI, etc. Providers are the API your agents call to think. Every persistent agent is bound to a provider; some are bound to multiple for fallback or for routing different work to different models.

Adding a plugin

The plugin install path is operator-mediated by design. Agents don’t install plugins mid-run; you do, in the Plugins surface in the operator portal’s Settings.

What the flow looks like:

• Propose / discover — Either you tell the CEO “we should add Slack,” or the CEO surfaces a proposal (“the customer-ops team needs a CRM connector”).
• Source approval — The plugin comes from a source. You approve the source before activation — it’s an authority decision, not just a configuration one.
• Policy validation — The plugin manifest declares what permissions it needs (which surfaces it touches, what it can read/write, what state it owns). Policy validation surfaces these so you can review.
• Scope — Most plugins start narrow — scoped to one team. If it earns wider adoption (via labs evidence or operational use), you can widen the scope later.
• Activation — The plugin goes live. The operator portal’s Plugins page shows it as installed, with its settings sections inline.

What to check before activating

• Permissions — What the plugin can read, write, emit, delete, hide, wake, display, route. The manifest declares it; the settings page shows it as tags. If a permission looks wrong for what the plugin is supposed to do, that’s a signal to investigate before activating.
• State ownership — Does the plugin own state? If yes, does it have export and recovery semantics? Plugins that capture important state without a way to migrate or recover it are traps.
• Runtime locks — The specific artifact versions the plugin is bound to. Pinned, not live. You shouldn’t get surprises from source-tree changes.

Removing or replacing a plugin

Plugin removal is the test of whether the boundary was real. If the plugin owned state, it should have an export path. Removing it should leave the company in a working state (perhaps without the capability the plugin provided, but operational).

Common reasons to remove or replace:

• The plugin didn’t earn its place in labs.
• A newer plugin does the same job better.
• The integration it provided is no longer needed.
• The plugin’s authority surface has shifted in a way you don’t want.

Configuring providers

Provider credentials live at two scopes: account-level (shared across all your exocorps) and per-exocorp. You manage them from:

• Account-level: platform dashboard — Account-wide provider credentials — useful when you want the same Anthropic API key across all your exocorps.
• Per-exocorp: operator portal settings — Provider bindings specific to one exocorp. Useful when a particular exocorp needs different routing, or when you want to bill providers separately per company.

When you bind a provider, the platform tells you which providers are required vs. optional for the exocorp to run. Required providers need credentials before the runtime will start; optional providers have fallback chains.