Skip to content
PRESHaiPRESHaiPRESHos Platform

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

Section titled “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.
Plugins in session: available capabilities with invoked tools and skills marked in the transcript

The flow: install → grant → session → invoke

Section titled “The flow: install → grant → session → invoke”

Four steps, in order. Skipping one is the usual reason a capability “should work” but does not.

  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.
  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.
  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 to grant to session to invoke: registries feed install on the left, the transcript closes invoke on the right

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.
  • Chrome Browser and Computer Use show Installed here; Google Drive, HubSpot, and Images remain Available until a tenant installs them.
Plugins registry with Installed and Available rows and Install actions

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.
Default Agent Plugins tab with per-plugin Enabled toggles

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.
Session run surface with run state, tasks, working folder, and environment-agent context

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

Registries are not session truth

Section titled “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

Section titled “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.
Session transcript showing chrome_browser invocation steps with Completed actions and observation details
  • 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

Section titled “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

Section titled “What next”