Run a mission
Write a mission with real success conditions, activate it, dispatch a fleet, watch it work in Terminals, and complete it through the gate.
This tutorial takes one mission through its whole life: written with explicit success conditions, activated, dispatched as a commander-led fleet you watch in the Terminals view, and completed through the enforced gate. Along the way you use every control that makes delegation safe — the pane you can type into, the pause pill, and the completion gate that refuses a quiet declaration of victory.
The scenario: a research deliverable — "produce a competitive brief on one rival product, grounded in material already in the workspace." A written deliverable is the right first mission: concrete, checkable, and nothing about it is irreversible.
One expectation set honestly up front: the board, the mission records, and single-agent mission work are everyday surfaces. The fully hands-off fleet run is designed and built, and it is best run with you watching — keep the Terminals view open for the whole walk, and treat the pause pill as your first control, not your last resort.
Prerequisites
- The quickstart tour, especially its Terminals and Missions steps.
- The mental model: Missions, operations & the fleet.
- Your Claude subscription connected — every fleet session is a full agent session on your own subscription (see BYO Claude & keys).
- Optional but recommended: a context artifact for the effort, so every fleet member starts briefed.
Step 1 — Create the mission
Open the Missions Board and click New Mission.
- Name it with a lowercase, hyphenated identifier — for example
rival-product-brief. - Write a one-line description of the goal.
- Optionally set a priority, dependencies, and a project grouping.
You should see: a card in the Planned column — and a working folder on disk immediately, holding the mission's dossier and an operations container. A fresh install ships an empty board; this card is yours from scratch.
Step 2 — Write the success conditions
Open the mission's dossier and spend one deliberate minute on the
Success Conditions — a checklist where each item carries an
— evidence: note describing what proves it. For the scenario:
## Success Conditions
- [ ] The brief covers pricing, positioning, and feature set — evidence: sections present in the deliverable
- [ ] Every claim cites a source document in the workspace — evidence: file references inline
- [ ] The deliverable lands in the mission folder as one Markdown file — evidence: the file existsThese checkboxes are not decoration. They are the completion gate in step 7, and the commander evaluates work against them. The sharper your checklist, the sharper the run — this is the highest-leverage minute of the whole tutorial.
Step 3 — Activate: choose Manual or Fleet
Move the mission to Active via the card's action menu. A chooser opens with two deliberately distinct paths:
- Manual activates without standing anything up — right when you drive the mission yourself or hand pieces to individual agents as you go. Activation is a status change, nothing more.
- Fleet activates and dispatches: it stands up a working fleet for the mission.
Choose Fleet for this walk. (On an already-active mission, the Dispatch button in the Mission Control bar does the same thing. One fleet per mission — dispatching again opens the existing workspace instead of starting a second fleet.)
Step 4 — Watch the fleet stand up in Terminals
Switch to the Terminals view.
You should see: a new terminal workspace holding the fleet — one commander pane, grounded with the mission dossier, and worker panes, each grounded with a thin role. Every one of them is a regular, visible, typable terminal; there is no hidden session type. Back on the board, the mission card shows a live agent strip with per-pane status dots — running, needs-attention, done — with the commander marked.
The commander now reads the mission, decomposes it into operations (one unit of work each), assigns one worker per operation, and dispatches each with a short kick message. Workers execute, write heavy output into their operation's working files, and report back short signals: done, blocked, or needs-attention.
Step 5 — Supervise: read, steer, pause
Three controls, all live while the fleet works:
- Read any pane. Watch the commander reason and the workers execute, line by line. Amber status dots mean a session needs you — a permission prompt or an idle wait.
- Type into any pane. A fleet member is an ordinary session; typing into it redirects that agent. You can message the commander the same way — it is just its pane.
- The agent-control pill in the Terminals toolbar shows
agent · N. One click pauses all agent terminal control: every mutating agent action is refused while paused and the pill turns amber, while reading stays available so you can inspect a paused fleet safely. Every mutating agent action on the terminal plane is also a line in the audit log on your disk.
Try the pause once during this walk, read the frozen fleet, and resume — knowing the brake works is the point of pressing it when nothing is wrong.
Step 6 — Tick the success conditions
As deliverables land, the success conditions get checked off — by the
commander as it verifies evidence during a fleet run, or by you directly:
the dossier is a plain Markdown file, and editing a [ ] to [x] is a
legitimate operator action the board picks up within a moment.
You should see: the goals meter on the mission card advance
(n/m met), and each goal recorded as an event in the mission's
Timeline (open Mission Control's Details disclosure). The operations
breakdown on the card moves toward terminal states in parallel.
Step 7 — Complete through the gate
When the work looks done, move the mission to Completed.
Completion is gated. The mission cannot complete until every success condition is checked and every operation has reached a terminal state. If the gate fails, the error names exactly what is unmet — an unchecked condition or a still-open operation — which is your punch list, not a fault. You can force-complete past the gate, but the override is recorded in the Timeline as a forced completion, permanently visible.
You should see: the card move to the Completed column. Nothing is deleted by the transition — the folder, dossier, operations, and Timeline all survive, and a completed mission can be re-activated later.
Where everything landed
| Artifact | Location |
|---|---|
| The deliverable and working documents | The mission's folder in your workspace |
| Operation briefs and working logs | The operations container inside the mission folder |
| The event history | The mission's Timeline (every transition, goal, and document, per mission) |
| The audit trail of agent terminal actions | The terminal-control audit log on disk |
The board itself is a projection of these files — you never repair a database, because the Markdown is the truth.
Where to go deeper
- Missions Board — every board control, Mission Control, lint, and the files-are-the-record model
- Terminals — workspaces, agent panes, session resume, and the pause pill in full
- Missions, operations & the fleet — the coordination model behind what you just watched
- The operator model — why the gates sit where they sit
- The agent roster — the specialists mission work draws on
From harvest to publish
Register a source, run a scheduled harvest, curate the pile into reports, dispatch a briefing writer, and take a newsletter through the send gate.
Build a knowledge product
Take a thesis and a folder of raw material through the staged Products pipeline — sight, research, scope, finalize, and export the two-component bundle.