Step 4 · State & operations · State & operations · Operator playbook ENPT
Factory Droid CLI Missions · Visual Course

Operator playbook

Supervise like a project manager: Mission Control, intervention patterns, and missionModelSettings.

Read the plain version, or open the technical layer on any section.
1

The big idea

Factory positions you as an agent project manager, not a line-by-line debugger. Mission Control (press Ctrl+T in the orchestrator session) shows active features, workers, progress log, token usage, and validation output.

It only works in orchestrator sessions. Binary string: "Mission Control is only available in orchestrator sessions. Run /missions and select + New Mission first."

When to intervene:

· Mission feels frozen → pause orchestrator, ask for re-assessment.
· Worker stuck → mark feature complete and move on.
· Scope changed → update plan via conversation; orchestrator propagates to artifacts.
· Validation failing → let fix-feature loop run; don't manually add validator features.

Configure models in ~/.factory/settings.json under missionModelSettings — separate worker and validation models, reasoning effort, optional skip flags.

Think of it like… an air-traffic control tower. You don't fly the planes (workers) or inspect every rivet (validators). You watch the board (Mission Control), clear holds (pause/unblock), and reroute when weather changes (scope shifts). The runway schedule (runner) keeps moving unless you explicitly stop it.

Mission Control data (MissionStore)

Active feature + full list, worker history, progress_log events, per-session token usage, validation summaries, controls: pause, redirect, unblock.

Daemon notifications

mission_state_changed, mission_features_changed, mission_progress_entry, mission_heartbeat, mission_worker_started, mission_worker_completed.

Enterprise

missionPolicy.restrictedAccess + allowedUserIds gates who can run missions.

Anti-patterns

Don't use droid exec --fork --mission. Don't treat ad hoc Task/worker as a substitute for start_mission_run. Don't skip mission-planning / define-mission-skills.

2

In one picture

Operator PM role Mission Control Ctrl+T · features · workers progress · tokens · validation pause · redirect · unblock Orchestrator mission-session only Runner + workers ~/.factory/settings.json · missionModelSettings
Operator ↔ Mission Control ↔ orchestrator ↔ runner. Model config sits in settings, inherited by worker and validator sessions.
3

In the code

Observed local settings and documented keys for mission model routing.

~/.factory/settings.json (local RE sample) 
{
  "hasSeenMissionOnboarding": true,
  "missionModelSettings": {
    "workerModel": "custom:kimi-k2.7-code-highspeed-3",
    "workerReasoningEffort": "xhigh",
    "validationWorkerModel": "custom:gpt-5.5-xhigh-2",
    "validationWorkerReasoningEffort": "xhigh"
  }
}
Additional documented keys 
"missionOrchestratorModel"
"missionOrchestratorReasoningEffort"
"missionModelSettings.skipScrutiny"
"missionModelSettings.skipUserTesting"
"keepSystemAwakeDuringMissions"  # default true

droid exec --mission

--worker-model <id>
--worker-reasoning-effort <level>
--validator-model <id>
--validator-reasoning-effort <level>

Factory's published model split example: orchestration on Opus-class, implementation on Sonnet/Opus, validation on GPT-5.3-Codex — roles are model-agnostic.

4

Try it: playbook + config builder

Scan the intervention checklist, then tune a sample missionModelSettings block.

Mission Control shows

  • Active feature + queue
  • Workers active / history
  • progress_log timeline
  • Token usage per session
  • Validation output

Operator moves

  • Pause / resume mission
  • Redirect scope via orchestrator chat
  • Mark stuck feature complete
  • Approve propose_mission
  • Unblock awaiting_input
You've completed the course. Re-run the verification commands from Lesson 1 on your own droid binary, inspect ~/.factory/missions/, and compare against the full RE report at docs/droid-cli-missions-reverse-engineering.md.