Goal orchestration
Mission Control
The surface for launching, observing, and steering durable goal runs.
What it is for
Mission Control turns a long-running objective into an inspectable, governable run. In current builds, the daemon persists the goal immediately and exposes prompt, current step, approvals, child-task state, and dossier/inventory outputs through goal-oriented surfaces whose depth varies by client.
Preflight at launch
- Goal prompt
- Primary agent provider/model/reasoning choice
- Role assignment roster
- Preset source and inherited defaults
The key idea is that launching a goal is not just “send prompt.” It is preparing a durable execution context.
During a run
Goal overview
Status, step position, approvals, controls, and objective summary.
Execution feed
Tool calls, file changes, messages, errors, and todo updates as they happen.
Thread router
Jump into the active execution thread and back again safely.
Dossier view
Evidence, step board, reports, and reflection outputs.
Today this is realized through a mix of shipped surfaces: the TUI goal workspace, task and approval views, daemon-backed inspection APIs, and evolving desktop goal views rather than one fully uniform shell everywhere.
Why it matters
Mission Control is what prevents durable autonomy from becoming opaque background automation. It keeps the operator attached to the real execution state without forcing manual babysitting of every turn.
Runtime edits
Goal-oriented surfaces can expose operator-safe runtime changes such as edits to the active role roster. The design distinguishes changes that apply on future work from changes that would affect the currently active step, even when client parity is still catching up.
Relation to threads
Goals is the orchestration surface; Threads is the conversational surface. tamux's current goal views make this distinction increasingly explicit instead of blurring everything into one chat stream.