Skip to content

The operating model

Spacedock runs on three roles and one division of labor: you shape the work and make the calls; the agents drive each item through its stages and bring decisions back to you with evidence.

Roles

Role Who Ownership
Captain You The mission, and the call at every approval gate unless delegated
First Officer The orchestrator agent Runs the workflow for you and brings each decision to you with evidence
Ensign The worker agent Moves one work item through one stage

Each session has one captain and one first officer; ensigns come and go with the work.

The first officer keeps the work moving so you do not have to: it finds what is ready, hands each item to a worker, and checks the result against the bar you set. Gated stages pause for your call; everything else flows forward without you.

Shaping versus driving

The captain shapes the product and owns the workflow; the agents drive. These are different jobs, and the split is what keeps you out of the per-step loop.

Shaping is the product judgment: the goal, the taste, the steering. What to build, what good looks like, which direction survives a gate. You make the calls at gates (approve, redo with feedback, or reject); some you answer yourself, others resolve through a delegated agent review. This judgment is the part the agents cannot supply.

Owning the workflow is the structural half. You set the stages and the bar each stage must clear, declared and serialized in the workflow README, starting from /spacedock:commission. The declaration is shapable mid-task: you do not have to get it right the first time. When a bar turns out fuzzy in practice, tighten the README and the next dispatch works to the new line.

Driving is moving work items through the declared stages. The first officer schedules and dispatches; the ensign does the stage work and proves it. The first officer acts on its own for routine, reversible steps and asks you only when something is genuinely ambiguous: unclear requirements, a design choice that would change the output, scope too vague to turn into criteria. Everything else happens without a prompt to you.

The line holds because of one rule: the maker does not judge its own work. Review runs as a separate stage with fresh context and no access to the maker's reasoning (see Gates and decisions). The first officer never self-approves a gated stage.

Batched, evidenced decisions

Decisions reach you batched and backed by evidence, not as a stream of interruptions. Your attention is the bottleneck; the agents queue work and surface only the calls that need a human.

Batch the work; decide as it flows back. Queue many work items at once. Ensigns advance each through its stages in parallel. You handle gates as they surface, not one session at a time, and not on the agent's schedule. While one item waits on a clarification, the first officer keeps dispatching the others.

Every gate carries evidence. The first officer does not hand you the transcript. It presents a short review: what was chosen, the evidence for it, and one recommendation you can approve with a single yes. Gates and decisions shows the format.

The decision leaves a trail. Each gate records the verdict and its reason alongside the stage report in the work item's file. The record outlives the reviewer, so a bad result traces back to the call that caused it. When you end a session, /spacedock:debrief captures what happened, and the next session picks up from it.

Where to go next