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.

Operations do one more thing worth knowing early: they size the fleet. A dispatched mission comes up with one commander plus one worker per open operation, so the operations you write before dispatching are what decide how much of the mission gets worked in parallel. Writing three operations and dispatching is a different act from dispatching an empty mission and hoping — and it is the same act, one minute earlier.

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.

How many workers is a question with an answer. The default is one commander plus one terminal per open operation, capped by a configuration key so auto-sizing can never stand up a fleet whose commander is then refused every further worker. Above that default sit two overrides: a durable Fleet field in the mission's own dossier, and the count you set in the launch dialog for one launch. Whichever wins, the pairing is shown as an editable plan before anything spawns — which pane commands, which operation each worker takes, and what is left unpaired. An operation with no worker is not an error; it is work the commander staffs or spawns for.

The commander reads the mission, assigns operations to workers, creates more as the shape of the work becomes clear, 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 a durable per-mission mailbox: every message is appended to a file in the mission's folder before anything else is attempted, and a restarted session rebuilds its picture from what is on disk. Live delivery into a running pane is a best-effort second step on top of that — a recipient that is stopped, sitting at a permission prompt, or parked on a dialog receives the message in the mailbox only, to be drained on its next turn. The practical consequence: when a worker appears to be ignoring an instruction, the mailbox is what to check, not the pane.

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.
• Reach is a setting, not a hope. How far a fleet's agents may go — read and report, edit files, or act outward — is chosen when the work is dispatched, and outbound sending sits behind its own master stop above that. Fleet agents are also briefed to bring the irreversible and the expensive back to you as questions, and they do; but the briefing is posture and the switches are the mechanism. Autonomy & controls states both, and which is which.

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
• Autonomy & controls — how far a dispatched agent may reach, and the switches that stop it
• Missions Board — every control in the cockpit, including the fleet plan
• 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