Plugins in session

Open in product: preshos.com/agent-ops/plugins-in-session

Plugins in session are capabilities at work: the tools and skills the running agent may invoke, drawn from the agent’s scope (prompt, model, tools, skills, memory) and what the environment grants. The session shows what is available; the transcript shows what actually fired.

The session UI

• The session surfaces which plugins, tools, and skills are active for this run. That list is the truth for this session — registries show what exists, the session shows what this run may call.
• Each invocation lands in the transcript: which capability fired, with what input, producing what result. An action with no transcript line did not happen here.
• A capability the session does not list is not one awkward phrasing away. Missing tools are a scope question for the tenant admin, not a prompt trick.

The flow: install → grant → session → invoke

Four steps, in order. Skipping one is the usual reason a capability “should work” but does not. The exception is the foundational set below: default Agent Ops agents arrive with those packages already installed and granted at provision time, so steps 1–2 are done before the tenant opens /ai/plugins.

1. Install. A tenant adopts a package from the plugin registry at /ai/plugins: Install moves it from available to installed for the tenant. Nothing runs yet — installed means adopted, not live. Foundational plugins skip this step on default agents: provisionAgentBundle installs them at provision time.
2. Grant. The installed plugin is enabled for specific agents (per-agent scope). An agent that was never granted the plugin cannot carry it into a session, no matter what the registry shows. Foundational plugins arrive pre-granted on default agents; OAuth and other opt-in connectors still need this step per agent.
3. Session. At session start the installs and grants resolve into the run’s plugin runtime (resolveAgentPluginRuntime): what this agent was granted, filtered through the environment policy (runner, repository linkage, sandbox timeout, tool grants, secrets). The session plugins panel shows that resolved set — it is the truth for this run.
4. Invoke. The agent calls a granted tool or follows a granted skill mid-run. Each call lands in the transcript with input and result. Invocation is the only proof the capability did anything here.

Install adopts the package for the tenant, grant scopes it to the agent, session resolves it at start, invoke proves it in the transcript. A capability missing from the session panel breaks at one of these four joints — walk backwards to find it.

Install adopts a package for the tenant at /ai/plugins. The registry header counts available versus installed; each row carries plugin, description, category, skills, version, and status, with Install on available rows and Manage on adopted ones.

• Installed means adopted, not live — nothing runs until an agent is granted the plugin.
• The foundational set shows Installed here on default tenants — preshos-records, images, chrome-browser, computer-use, documents-pdf, documents-spreadsheet, documents-word — installed and granted at provision time. OAuth and other opt-in connectors (Google Drive, HubSpot) remain Available until a tenant installs them.

Foundational plugins: installed and granted at provision

Default Agent Ops agents do not go through install → grant for the foundational set. At provisionAgentBundle the tenant’s default agents get install+grant of seven packages in one move:

• preshos-records, images, chrome-browser, computer-use, documents-pdf, documents-spreadsheet, documents-word

That means the session panel lists these capabilities from the first run — no registry Install, no per-agent toggle — subject only to the session environment policy. What still needs the manual path is everything opt-in: OAuth connectors and tenant-adopted packages keep the install → grant → session → invoke flow above, because they carry credentials or tenant-specific bindings the platform cannot assume.

• A foundational capability missing from the session panel breaks at environment scope or agent configuration, not at install. Walk backwards from session, not from the registry.
• Turning a foundational plugin off for an agent is the per-agent Enabled toggle, not an uninstall — the package stays adopted for the tenant.

Grant enables the installed plugin for specific agents. On the agent’s Tools and Plugins Plugins tab, each row shows workspace status with an Enabled toggle — Active plugins switched on, Not installed rows off.

• An agent never granted the plugin cannot carry it into a session, whatever the registry shows.
• Grant scope is per agent: the same plugin can be on for one agent and off for another.

The session surface is the truth for the run: run state with logs access, tasks, working folder, and context binding the run to its environment and agent. The session plugins panel on this same surface lists what this run may actually call — registries show what exists, this run shows what is available here.

• A capability the session does not list is not one awkward phrasing away; it is a grant-or-environment question.
• The transcript beside it proves what fired: an action with no transcript line did not happen here.

Where install and grant disagree, deny wins: a denied capability never reaches the session runtime, even if an install row exists for the tenant.

Composer tags: hydrating allowed plugins for one run

Members can tag allowed plugins from the composer to hydrate capabilities for that run. Tagging names which of the agent’s allowed plugins this run should carry — it selects within what install, grant, and Tool Policy already permit; it never grants what the agent was not granted.

• Tag the plugin the task needs, not every plugin available. Untagged allowed plugins stay out of the run’s resolved set.
• A tag on a plugin the agent was never granted, or the Tool Policy denies, changes nothing in the session panel — that is a grant-or-policy question, not a tagging problem. Walk the flow backwards: tagged? → granted to this agent? → installed for this tenant? → allowed by the environment policy?
• Treat the product UI as the source of truth for the exact tag interaction. Tag names this page does not list are not promised.

Registries are not session truth

Registries answer “what exists.” The session answers “what this run may call.” Keep the two apart:

• The plugin registry lists installable packages and their status. It never promises a running session can reach them.
• The tool registry names what each atomic tool does. The skill registry names the procedures agents follow. Both describe building blocks, not live scope.
• The environment tool list is the live scope. If a system is not listed there, sessions cannot reach it no matter what any registry suggests.
• When a capability is missing from the session panel, walk the flow backwards: invoked? → in session scope? → granted to this agent? → installed for this tenant? The break is usually at grant or environment, not at install.

How tools and skills get invoked

Invoke is proven in the transcript, one fired step at a time. This run narrates each chrome_browser move — page loaded then filling the note and saving, value entered then clicking Save, saved value then reloading to verify persistence — with Completed 2 Actions rows and observation details beside them. The run also shows the honest failure path first: the Chrome connector unavailable until the managed extension reconnects, refusing the sandbox headless substitute because it would not validate what was asked.

• Each invocation names what fired, with what input, producing what result; an action with no transcript line did not happen here.
• “Completed actions” rows plus observation detail are the receipt — read them before trusting the outcome.

• Tools fire for atomic steps: reads first, writes through the approval gate. The tool registry names what each tool does; the session decides when.
• Skills shape how the agent works: repeatable procedures the agent follows with its granted tools. Skills guide behavior; they never grant new capability on their own.
• Plugin packages arrive as one unit — skills, tools, and wiring adopted together — then enable per agent. What the agent carries into the session is set at configuration time, not mid-thread.

MCP in session

MCP servers reach a session the same way plugins do: catalog or custom install first, grant to the agent second, environment scope third. Only granted installs are callable — a server that is installed for the tenant but never granted to this agent does not appear in the session, and the session cannot improvise access to it. Sessions carry zero credentials: auth arrives as grants, and raw credential material never enters the session. Catalog servers (platform-managed, frozen fingerprints) and custom tenant servers behave identically at invoke time; they differ only in how they were installed and rechecked. Full reference: MCP registry.

What next

• Plugin registry: the installable packages sessions draw on — foundational set versus opt-in.
• Document tools: the documents-pdf, documents-spreadsheet, and documents-word foundational packages — what each tool reads and writes.
• Tool registry: the atomic capabilities behind invocations.
• Skill registry: the procedures agents follow.
• MCP registry: catalog vs. custom installs and session grants.
• Environments: the scope sessions start from.
• Voice / GPT-Live: voice plugin settings and what a voice run may call.
• RBAC in Agent Ops: who may run which capabilities.