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.

The shared plugin page shape

Each plugin carries a shared manifest-driven page: one manifest behind what the registry row, the agent Plugins tab, and the session panel each show. The registry lists the package, the agent Plugins tab scopes it per agent with the Enabled toggle, and the session panel shows the resolved set for the run — all three read the same manifest, none of them redefines it.

• Manifest is the definition: bundled skills, tools, and wiring travel as one unit with the package’s version. Adopting the package adopts the manifest; there is no partial adopt.
• Registry row is the tenant view: Installed / Available status, category, skills, version. Install moves the package from available to adopted — nothing runs yet.
• Agent Plugins tab is the grant view: per-agent Enabled toggles scope the adopted package to the agents that may carry it. See Plugins in session.
• What the session lists is the resolved view: manifest through grant, Tool Policy, and environment policy. A row the registry shows but the session does not is a grant-or-policy gap, not a second definition.
• Treat the product UI as the source of truth for manifest fields this page does not name. Field-level mechanics beyond status, category, skills, and version are not promised here.

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.

Foundational vs. opt-in

Two kinds of rows live at /ai/plugins:

• Foundational. Installed and granted to default Agent Ops agents at provision time (provisionAgentBundle): preshos-records, images, chrome-browser, computer-use, documents-pdf, documents-spreadsheet, documents-word. These show Installed from the first login; sessions carry them subject only to environment policy. See Plugins in session.
• Opt-in. Everything else — OAuth connectors (Google Drive, HubSpot) and tenant-adopted packages. These stay Available until a tenant installs them, then need a per-agent grant before any session lists them. Install adopts the package for the tenant; the grant scopes it to the agent.

When a capability is missing from a session, check which kind it is first: a foundational gap is an environment or agent-configuration question, an opt-in gap is usually a skipped install or grant.

PRESH master directory: publish and push

PRESH platform teams can publish packages to a master plugin directory and push updates to tenants from it. Tenants still install: a pushed package appears for the tenant to adopt through the same Install → grant → session flow above — pushes do not force-install into sessions.

• Pushes preserve tenant state: credentials, grants, and paused status survive a push. A tenant that paused a package stays paused after the update lands.
• Local edits opt out: a tenant that edited the package or its logo locally stops tracking the master copy for those parts. Treat the product UI as the source of truth for the exact publish, push, and opt-out controls.
• Verify after a push like any other adoption change: confirm the version row, then a test session. See Plugins in session.

What next

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