Plugins

What a plugin is

A plugin is an installable extension boundary — a governed crossing between the exocorp and capability outside its core. The boundary matters more than the package itself. Without a boundary, every useful integration becomes platform work and the runtime grows too thick. With a boundary, the company can borrow capability, place it, test it, govern it, and replace it.

A plugin is not primarily an agent-facing tool. It’s substrate extension. Agent use is one case; runtime modularity is the larger design.

What plugins can extend

• Agent-facing capabilities — Browsers, calendars, code hosts, messaging systems. Tools agents call during work. These usually need attached skills to be used well, not just exposed.
• Workflow surfaces — Schedules, triggers, routing, queues. Plugins that shape when work happens and how it moves between teams.
• Memory surfaces — External knowledge stores, retrieval systems, knowledge graphs, sync to outside corpora.
• Operator surfaces — Dashboards, review surfaces, debugging tools, projections. Plugins that contribute to what the operator sees.
• Runtime surfaces — Secret custody, model routing, sandboxing, storage, deployment. Plugins that change how the runtime itself operates.
• Harness surfaces — Session behavior, tool repertoires, skill systems, delegation patterns, memory adapters, communication. The shape of how an agent works.

How plugins are installed

The normal install path is operator-mediated, not agent-driven: a template proposes the plugin; the operator approves the source; policy is validated; a snapshot is taken; the plugin is activated. Agents don’t install plugins mid-run. That separation is intentional — the plugin model is about governed extension, not on-the-fly dependency injection.

Once installed, a plugin’s manifest declares its identity, version, compatibility, scope, required permissions, configuration, runtime processes, contributions, UI surfaces, tools, schedules, handlers, and providers. The host reads the manifest before running the plugin.

Scope

Plugins are scoped to where they belong:

• Organization-wide — Things like the shell, the knowledgebase view, an observability surface. Affect the whole exocorp.
• Team-level — A sales connector, a research dataset, a support channel. Only attached to teams that need them.
• Agent-level — A role-specific tool or private data source. Even more narrowly attached.

Scope moves with evidence. Something might start attached to one team, prove itself, and be promoted to organization scope. Or it might fail at a small scope and be removed before it spreads.

Failure modes

• Core absorption — Every useful extension becomes a core feature, and the runtime grows too thick to maintain.
• Tool collapse — Every plugin gets treated as if it’s an agent-facing tool, even when it’s really a runtime, operator, or workflow boundary.
• Hidden authority — A plugin shapes belief, attention, external promises, or operator visibility without being understood as an authority surface.
• State capture — A plugin becomes the owner of important state without export, recovery, migration, retention, or replacement semantics.
• Live-source drift — The runtime depends on mutable source trees, remote refs, or package-manager state instead of immutable snapshots.
• Irreversible adoption — Capability enters through a boundary, but the boundary wasn’t designed for exit.