Control Room

The Control Room is the pane you run the fleet from. It's shaped like an IDE, but you don't drive it by typing code — you drive it by talking to an orchestrator that plans the work, hands it to agents, watches them, and brings the results back for your review. Think air-traffic control for coding agents: you say what you want built; o8 decides how, who builds what, in what order, and whether it's safe to ship.

Three things make it not a code editor:

• You issue intent, not keystrokes. The main act is a sentence to the orchestrator, not an edit to a buffer.
• Work runs in the background, in parallel — several agents in isolated worktrees at once. You watch status; you don't babysit one file.
• Nothing the agents do is trusted blindly. A governance layer sits between their output and your main branch, and review is a first-class surface (see Review & approval).

What's on screen

The orchestrator chat

This is how you drive everything. Open an Orchestrator tab and it starts compose-first — "What should we build?" — with editable context chips (project, worktree, branch) until your first message lands.

What you say becomes work. The orchestrator plans (breaks your intent into packets with an order), dispatches them to agents in isolated worktrees, watches progress, and reports back inline — turn summaries, action cards, and live activity as agents run, including when a worker consulted the Brain. You steer by replying in the same thread; you rarely touch the agents directly.

Your main throttle on autonomy is the permission mode. The chat runs in full access by default. Switch it to plan and a read-only banner appears: the orchestrator proposes and plans but won't make changes until you switch back. Plan first when you want to see the shape of the work before anything runs.

Sessions

Your conversations are durable and resumable. A session is a conversation thread inside a runtime — leave, come back, reopen a thread from the left column, and continue where it left off. Sessions sit inside the primitive chain from Concepts: a runtime (the agent adapter) carries many sessions, and a lane binds a session to a worktree and a packet for one piece of execution.

o8.md — the workspace spec

o8.md is a plain-markdown file at the root of your repo: your working document of what should be built. It's the shared source of intent between you and the fleet — and the rule is simple: you author it, agents annotate it, nobody overwrites it.

Agents leave threaded comments and non-destructive suggestions on the spec rather than rewriting it; you resolve the threads. In the app, the spec tab is the review surface for o8.md — threads, suggestions, and resolve state, with "Ask the Brain" beside it.

From inside a worktree, an agent works the spec through the o8 CLI — never by clobbering the file:

The flow: you write the spec, the fleet reads and annotates it, you resolve the threads. The spec stays a reviewable source of intent, not a file agents rewrite.