Factory Droid CLI Missions · Visual Course

What Missions is (and isn't)

By the end you'll know Missions is an interaction mode — not a CLI subcommand — and which entry points actually start it.

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

The big idea

Missions is Factory Droid's long-horizon way to build multi-feature software. You describe a project, the system plans it, workers implement feature by feature, and validators check each milestone before moving on. Median missions run about two hours; some last days.

Here's the surprise from reverse engineering droid 0.150.1: there is no droid mission subcommand. Missions is an interaction mode — the session flag interactionMode: "mission" — entered through slash commands in the TUI or through droid exec --mission headless.

When you enter Missions, the CLI spins up a fresh orchestrator session tagged mission-session. That session plans work, writes durable files under ~/.factory/missions/<uuid>/, and eventually calls start_mission_run to hand off to a programmatic runner. State lives on disk, not in chat memory.

Think of it like… switching a construction site from "walk-in consultation" to "formal project mode." You don't run a new app — you change how the same Droid CLI behaves. The site office (orchestrator) keeps the blueprints on file; crews (workers) arrive fresh per task; inspectors (validators) sign off at each floor. Unlike a one-shot chat, the blueprints persist even if you close the terminal.

Under the hood

Top-level subcommands in v0.150.1: exec, daemon, search, update, mcp, plugin, computer — no mission.

TUI entry: /missions, /mission, /enter-mission. Binary strings: Entered Mission mode., Already in Mission mode., Mission mode starts a fresh orchestrator session (conflicts with --fork --mission).

Headless entry requires --auto high or --skip-permissions-unsafe, plus a prompt or -f mission.md. Output includes Mission started: with missionId.

System	Primitive	Work unit	Shared state
Droid Missions	`interactionMode: mission`	Feature + milestone	`~/.factory/missions/<uuid>/`
Kimi AgentSwarm	Tool `AgentSwarm` + `/swarm`	Item in `items[]`	`agents/<id>/wire.jsonl`
Claude Dynamic Workflows	Tool `Workflow` + script VM	`agent()` in JS	`workflows/scripts/*.js`

In one picture

Left → right: valid entry points flip interactionMode to mission and create an orchestrator session; state materializes on disk. The dashed box is what does not exist.

In the code

Two real ways in — TUI slash command and headless exec. One command that people expect but isn't there.

droid exec --help (v0.150.1)

# Headless mission entry
droid exec --mission \
  --auto high \
  --worker-model <id> \
  --worker-reasoning-effort <level> \
  --validator-model <id> \
  --validator-reasoning-effort <level> \
  -f mission.md

# These do NOT exist:
droid mission    # ✗ no subcommand
droid missions   # ✗ no subcommand

~/.factory/sessions/…/2382c4e6-….settings.json (local RE evidence)

{
  "interactionMode": "mission",
  "tags": [{
    "name": "mission-session",
    "metadata": {
      "role": "orchestrator",
      "missionId": "2382c4e6-f93d-4cb1-b94c-c1bfaf86c2c0"
    }
  }]
}

Reproducible checks

droid --version
droid exec --help | rg mission
droid --help   # confirm no mission subcommand
jq '.interactionMode, .tags' \
  ~/.factory/sessions/*/2382c4e6-*.settings.json
strings -a ~/.local/bin/droid | rg 'propose_mission|start_mission_run'

Try it: pick an entry point

Click each button. Watch what the CLI would do — and which paths are dead ends.

Questions welcome — bring your own droid --help output if versions differ. Next: how Orchestrator, Worker, and Validator divide the work once you've entered mission mode.