Plugin registry

The plugin registry is the agent-config building block for installable capability packages: bundled skills, tools, and wiring a tenant adopts as one unit. The registry surface is /ai/plugins: add capabilities to your workspace, then enable them for your agents. Each row carries plugin, description, category, skills, version, and status; available rows show Install, adopted rows show Manage. Package mechanics beyond that are not documented in source yet.

• Adopt one package per need. A plugin built on broken tools teaches the agent to fail confidently; verify each tool standalone first.
• Scope is per tenant and per org. An install in the wrong org scope reaches another tenant’s data or nothing at all; confirm where the install landed.
• Connector-backed capabilities inside a plugin are only real when their bindings exist for the tenant: org, package, and connection coordinates, not “the connector exists.”
• Gate the risky parts. Plugin actions that are irreversible, customer-visible, or cross-system pause for a named approver role.
• Record what you adopted: package, version, scope, verification date. The header counts tell the story at a glance: available to install vs. installed. The pilot reads that register; the handoff hands it over.

Treat /ai/plugins as the source of truth for plugin surfaces. Do not promise stakeholders coverage from package code alone; check the tenant’s environment tool list. Related: Skill registry, Tool registry, MCP registry.

What next

• Plugins in session: the install → grant → session → invoke flow — registries show what exists, the session shows what a run may call.
• Chrome browser: the chrome_browser package path — install, claim per run, reconnect is a new run.
• Computer use: the desktop-bridge package path for OS-level work.