Operator

The operator is an owner-scoped chat in the web app, reachable from Mission Control's Details panel. It is not a second, smaller tool set: it calls the same command registry as the MCP endpoint and the plugin's operator agent, with the caller's own authority — so it can create a project, plan a release, dispatch work, and ask a person to ship it, in one conversation. It is not a shell, and it cannot approve, merge, or ship its own work.

Where it lives

Open Mission Control, select an owner-scoped workspace (not Account machines), and toggle Details. An Operator tab appears beside the inspector; on a wide layout the operator panel stays open next to it instead of replacing it. See Mission Control.

What it can do

The operator runs the full lifecycle registry — projects, documents, plan, releases, dispatch, ship — with two exceptions it has no use for in a chat: attach_screenshot and create_ask stay off its tool list. Everything else that the credential's scopes allow is reachable, in multi-step tool use: a single turn can call several tools in sequence, up to 8 model calls and 25 tool calls, inside a 300-second turn lease.

Send a message in the Operator message field and watch its tool calls appear as chips while the turn streams; Send is disabled until the turn settles. Sending the same turn id again replays the stored result instead of starting a second generation, so a retried submit or a flaky connection never double-runs a turn.

Approvals

Exactly like an agent calling MCP, an approval-class command never executes for the operator — it files an approval and returns {status: "approval_required", action_id, ask_id}. The card that results:

appears inline under the turn that raised it,
on the owner's Needs you list, and
on the Mission Control rail's Approvals card,

labelled Operator as who raised it. A person decides with Approve or Reject on the card itself; the operator never sees a confirmation and cannot supply one on a person's behalf.

Owner policy

A checkbox in the operator panel, Ask me before dispatching work, moves dispatch_work and a dispatch_control retry into the same approval flow — unchecked, both run directly within the owner's existing authority. Only an org admin can change it; anyone else's attempt is refused. This policy only ever adds approval to dispatch and retry: delete, mark-done, ship, unlock and publish stay approval-class regardless of how it is set.

Model and billing

The operator runs on the house key under the same assistant-turn metering as the rest of the app; an owner's own BYOK OpenRouter key is honoured if one is configured.

What the operator cannot do

There is no shell, generic RPC, SQL, or file-write tool. It cannot merge a pull request, approve its own prepared action, or close an issue Done or a release Shipped — those stay a person's click, exactly as they do for every other agent on MCP. Production deploy stays under the release's existing human merge trigger.

MCP — the full tool catalog, scopes and approval-class rules the operator shares
Mission Control — the panel that hosts the operator and its Approvals card
Plugin — the operator skill and agent that drive the same registry from a terminal