The operator model

Command Center is built on one working model, and every surface in the product expresses it: you direct, agents execute. You think in systems — what should exist, what done looks like, what must never happen — and you hand the execution to agents that read your intent from files, do the work in the open, and come back for judgment at the moments that matter.

Once this model clicks, the rest of the platform reads as one coherent machine. Until it clicks, the platform looks like a large collection of views. Start here.

Two doors into one room

Every capability in Command Center has two surfaces: the view you click, and a tool an agent can call. Both drive the same backend. The Cortex graph you browse is the same graph your agents query; the Missions Board you read is the same mission state a fleet works against; the terminal panes you watch are the sessions your agents run in.

The consequence is worth stating plainly: directing an agent is never a degraded path. The capability surface is mirrored — what you do in a view, an agent can do on your instruction — which is what makes "describe the outcome, dispatch the work" a real working method rather than a slogan.

One thing is deliberately not mirrored: the controls over agents themselves. No agent is given a tool that flips a control plane — there is no "enable my own reach" verb anywhere in the tool fabric, the switches are operator surfaces in Settings, and every change is recorded with who made it. That asymmetry is what makes this a system you delegate to rather than one that delegates to itself.

Be precise about how far that goes, though, because the honest version is more useful than the reassuring one. It is a missing capability, not a sealed boundary. The switches are stored in your configuration file inside the workspace, and an agent you have given file-editing reach can edit files. Nothing in the product stops a sufficiently determined agent from rewriting that file, any more than it stops one from editing your notes — you own the machine, and so does anything you hand the keys to. What the design guarantees is narrower and still worth having: an agent cannot widen its own reach through the product, and it cannot do so quietly.

Competence comes from files, not memory

A freshly started agent knows nothing. It becomes competent by reading: the operating contract at the root of your workspace, its own agent definition, the protocols that govern how work is done, and whatever context you attach to its session. All of these are plain Markdown files you can open, read, and edit — and edits take effect the next time an agent starts.

This is the platform's core design bet: the intelligence lives in the model, but the competence lives in the architecture. You improve your system by editing documents, not by retraining anything.

Where you stay in the loop

Delegation is only useful if it is safe. The platform keeps you in the loop three ways — and it is worth separating the ones that are mechanisms from the one that is posture, because only a mechanism holds when an agent is wrong.

• Everything runs in the open. Agents dispatched as a fleet work inside regular terminal panes in the Terminals view. You watch them type, you can click into any pane and take over, and one control pauses all agent terminal activity at once. Every mutating agent action on the terminal plane is written to an audit log. Mechanism.
• Reach is a setting you own. How far a dispatched agent may reach — read and report, edit files, or act outward by sending and publishing — is chosen per dispatch, and outbound sending sits behind its own master stop on top of that. Customer-facing messages are drafted for your approval as the standing posture; a dispatch you deliberately set to act outward does act outward, and owes you an account in its report of exactly what went out. What binds is the switch, not a sentence in a briefing. Mechanism. The full model — the levels, the switches, what each one does and does not cover — is on Autonomy & controls. Read it before you leave an agent running unattended.
• Big decisions escalate. Agents are briefed to decide the tactical and reversible on their own (which file to edit, how to sequence a build) and to bring the strategic, the irreversible, and the expensive back to you as questions. Posture — it is how agents are instructed, and it works, but an instruction to a model is not a gate. The gates are the two above.

What the model asks of you

The operator's job is small in volume and high in leverage:

1. Write intent down. Standing priorities and constraints go on the blackboard; larger goals become missions with explicit success conditions; task context becomes a context artifact.
2. Dispatch the right surface. A quick bounded job goes to a one-shot agent; recurring work becomes a routine; a long, watched, multi-part effort becomes a mission fleet.
3. Judge the output. You evaluate results against what you asked for, approve what is waiting on your decision, and correct course by editing the files agents read.

You do not write the detail. You decide what the detail should achieve.

Where to go next

• Autonomy & controls — how far an agent may reach, and every switch that turns it down
• Missions, operations & the fleet — how larger goals become coordinated multi-agent work
• Context artifacts & grounding — how a fresh session starts already knowing your task
• Routines & automation — the scheduled arm of the same model
• The agent roster — the specialists you direct