Run a mission

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 agent CLI signed in — every fleet pane is a full agent session on your own subscription (see BYO Claude & keys).
• The Missions Board and Terminals are Pro surfaces — see Tiers: Pro & Ultra.
• 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.

1. Name it with a lowercase, hyphenated identifier — for example rival-product-brief.
2. Write a one-line description of the goal.
3. 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 exists

These checkboxes are not decoration. They are the completion gate in step 9, 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 — Pre-stage the operations, because they size the fleet

A fleet comes up with one commander plus one terminal per open operation. A mission with no operations does not get a smaller fleet — it falls back to your saved default for fleet launches and every worker comes up idle, waiting for the commander to invent its work. That is a legitimate way to run a mission, and it is not the one to learn on.

So write the work down first. Select the mission and click + New Operation in the Mission Control bar (the mission's row in the sidebar tree offers the same action). Each one takes a name, a brief stating its scope and what counts as done, and a starting status — leave it at planned, which is what the fleet pairs against. Three is a good number for this scenario:

• pricing-and-packaging — what the rival charges, and for what
• positioning-and-claims — who they say it is for, and what they claim
• feature-comparison — feature by feature, against ours

You should see: the card's operations breakdown pick up three planned operations, and each one appear as its own folder in the mission's operations container. The dossier also grows a machine-rendered ## Operations index listing them — read it, do not edit it. It is rewritten from the folders on every reconcile, and an operation's folder name is what carries its status.

Step 4 — Activate: choose Manual or Fleet

Move the mission to Active — drag the card into the Active column, or use the card's action menu. Either way the same 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.)

You should see: before the chooser commits to anything, it previews what Fleet resolves to — 4 terminals · 3 operations for the mission you just staged. If that reads 2 terminals · 0 operations, step 3 did not land: the fleet is about to come up on the fallback default.

Step 5 — Approve the fleet plan

Fleet opens the launch dialog, and it opens showing the pairing rather than performing it silently. One row per terminal:

1. Check the count. With Match operations on, it follows the mission — four terminals for three operations. Turn it off to pin a number yourself; a Match operations · N button appears whenever your number and the mission's disagree.
2. Check the commander star. Row one by default. Click another row's star to move it; a commander owns no operation.
3. Check the pairings. Every worker row picks its operation from a list of the mission's open ones. Assigning one another row already holds moves it rather than duplicating it.
4. Read the line under the table. It says how many operations are assigned, which are orphaned, and how many workers are floaters. Orphans and floaters are legitimate — the point is meeting them here rather than in a summary afterwards.
5. Optionally attach context and a first message. A Global context is inherited by every pane on top of its mission grounding — this is where the artifact from Ground a session goes. A First message targeted at the whole fleet is appended to the commander's kickoff and to every worker's opening message; use it for a standing constraint the whole fleet must honour, not for an instruction to one agent.

Launch when the table reads the way you meant it.

Step 6 — 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 the commander role, and worker panes, each grounded with the dossier, a thin worker role, and its one operation. The pane names carry the pairing: commander, worker · pricing-and-packaging, and so on, with worker · idle for a floater. 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 works the mission against the plan: it briefs its workers, creates further operations as the shape of the work becomes clear, and evaluates results against the success conditions. Workers execute their one operation, write heavy output into its working files, and report back short signals: done, blocked, or needs-attention.

Step 7 — 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.

If a worker looks like it is ignoring the commander, check the mailbox, not the pane. Fleet messages are appended to a durable per-mission mailbox file first and delivered live second. A pane that is stopped, waiting at a permission prompt, or parked on a dialog gets the message in the mailbox only, and drains it on its next turn — so "nothing happened" usually means "not yet", and the mailbox file in the mission's folder is where you confirm it.

Step 8 — 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 9 — 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

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
• Autonomy & controls — read this before you run one of these unwatched
• Calendar — putting a mission work block on a moment you will not be at the machine
• The operator model — why the gates sit where they sit
• The agent roster — the specialists mission work draws on