Missions, operations & the fleet

A single prompt is fine for a single task. Real goals — build a feature, produce a research corpus, overhaul a subsystem — span days, sessions, and multiple agents. Missions are how Command Center gives that kind of goal a durable home, and the fleet is how a mission gets worked by more than one agent at once, in front of you.

Missions: goals with a home

A mission is a standing mandate with three durable parts:

• A registry entry in the missions log — the mission's identity, status, priority, and dependencies. The log is the single source of truth for what missions exist and where they stand.
• A working folder — created the moment the mission is, even while it is still just planned. The mission's narrative document (its dossier), its accumulated working documents, and its operations all live here. The folder name carries the mission's status, so the filesystem itself tells you the state of the portfolio.
• Success conditions — an explicit checklist in the dossier defining what done means. This is not decoration: a mission cannot complete while conditions remain unmet, so writing them well is the highest-leverage minute you spend on any mission.

Missions move through a simple lifecycle — planned, active, then completed or cancelled, with archiving as a filing step — and nothing is ever deleted along the way. A finished mission keeps its folder, its history, and its registry entry.

Operations are the units of work inside a mission: each one a small folder with a brief stating its scope and what counts as done. An operation can be worked by a single agent, or become one worker's assignment in a fleet. Every operation belongs to a mission — there is no orphan work.

The Missions Board: your cockpit

The Missions Board view projects all of this onto a live Kanban: columns for planned, active, completed, and cancelled missions, with cards showing priority, a goals meter, per-operation progress, and dependency status. Selecting a mission surfaces Mission Control — the control strip for status changes, priority, dependencies, renames, and dispatch — plus a timeline of everything that has happened to the mission.

One design fact keeps the board trustworthy: the Markdown is the record; the board is a projection of it. You or an agent can edit mission files directly, and the board catches up within a moment. The projection can even be discarded entirely and rebuilt from the files. You never manage a database — you manage documents.

Two verbs on the board are deliberately distinct. Activating a mission makes it your working focus — a status change, nothing more, right for missions you drive yourself. Dispatching a mission stands up a fleet to work it.

The fleet: one commander, visible workers

A dispatched mission runs as a commander-led fleet: one commander agent and a set of worker agents, each a full-capability session in its own terminal pane, all inside one workspace in the Terminals view.

The commander reads the mission, breaks it into operations, assigns each to a worker, and evaluates results against the success conditions. Workers execute their one operation, write durable output into the operation's folder, and report done or blocked. Coordination happens through messages backed by a durable per-mission mailbox — so a message never gets lost, and a restarted session rebuilds its picture from what is on disk.

The shape is deliberately flat: one commander, workers beside it, no hidden sub-hierarchies. What you see in the Terminals view is the fleet.

You remain the operator

The fleet works for you, not instead of you:

• Watch everything live. Every fleet member is a regular, visible terminal. Click into any pane to see exactly what an agent is doing — or type into it and take over.
• Pause with one control. A single switch freezes all agent terminal activity; reading remains available, so you can inspect a paused fleet safely.
• Completion is gated. A mission can only complete when every success condition is checked off with evidence and every operation has reached a terminal state. No quiet declarations of victory.
• Judgment escalates. Irreversible, expensive, or outbound actions come back to you, exactly as the operator model promises.

A practical note on maturity: the mission board, the mission records, and single-agent mission work are everyday surfaces. The fully hands-off fleet run — commander staffs, drives, and closes a mission unattended — is designed and built, and it is best run with you watching in the Terminals view, which the platform makes effortless.

Where to go next

• The operator model — the division of labor the fleet is built on
• Context artifacts & grounding — how fleet members start already briefed
• Routines & automation — when scheduled automation fits better than a mission
• The agent roster — the specialists a fleet draws on