Three roles, one programmatic runner: plan upfront, implement feature-by-feature, validate at milestones.
Missions splits agent work into three layers that don't share one bloated chat thread.
Orchestrator — the project manager. One long-lived session with interactionMode: mission. It writes the validation contract before locking features, maintains shared artifacts, calls propose_mission for your approval, then start_mission_run. It does not accumulate implementation detail.
Worker — the implementer. The mission runner spawns a fresh session per feature from features.json. Each worker gets one spec + a skill file, implements with local TDD, and returns a structured handoff JSON. Workers don't declare "done" — validators do.
Validator — the inspector. When a milestone's features complete, the system auto-injects scrutiny-validator and user-testing-validator features. Sub-droids review code and test real user flows against assertion IDs in the validation contract. Failures become fix features; the loop repeats.
Think of it like… a film production. The director (orchestrator) holds the script and schedule but doesn't operate every camera. Each scene gets a dedicated crew (worker) with a clean call sheet. At the end of each act, quality control (validators) runs dailies and reshoot lists before the next act starts. The director never manually picks "take 47" for every shot — a programmatic runner advances the queue.
mission-orchestrator, mission-worker, mission-session tag. Child sessions indexed via decompMissionId in session-discovery-index.json.
Programmatic loop post-start_mission_run: "takes the feature list and spawns a worker for each feature in order." Resuming after pause picks up the pending feature — no arbitrary skip. Cost heuristic: total runs ≈ #features + 2 × #milestones (+ fix rounds).
Binary prompt: NEVER create features with skillName scrutiny-validator or user-testing-validator — system auto-injects them at milestone end.
Orchestrator may call Task with subagent_type: "worker" for exploration — distinct from the formal runner executing features.json.
USER → /missions or droid exec --mission
→ ORCHESTRATOR (interactionMode=mission)
→ mission-planning + define-mission-skills
→ ~/.factory/missions/<uuid>/
→ propose_mission → (approve) → start_mission_run
→ MISSION RUNNER (programmatic, sequential)
→ FEATURE WORKER (fresh session each)
→ handoffs/*.json
→ milestone? → scrutiny-validator + user-testing-validator
→ pass? → next milestone : fix features → re-validate
→ MISSION CONTROL (Ctrl+T, orchestrator only)
The orchestrator's two mission-specific tools and the progress events the runner emits.
# Orchestrator tools propose_mission # present proposal to operator start_mission_run # kick programmatic runner # Progress events (progress_log.jsonl) mission_run_started worker_started worker_selected_feature worker_completed worker_failed milestone_validation_triggered # Validator skillNames (auto-injected — do NOT add manually) scrutiny-validator user-testing-validator~/.factory/droids/ (custom sub-droids)
worker.md # generic feature worker scrutiny-feature-reviewer.md # per-feature code audit user-testing-flow-validator.md # assertion IDs from contract
planning → awaiting_input → initializing → running ↔ paused / orchestrator_turn → completed | cancelled
Click each role. See what it owns — and what it deliberately does not do.