Skip to main content

Configuration inheritance

Missions inherit your existing Droid configuration:
  • MCP integrations — Workers can use your connected tools (Linear, Sentry, Notion, etc.)
  • Custom skills — Your existing skills are available and new ones can be developed during planning.
  • Hooks — Lifecycle hooks fire during mission execution.
  • Custom droids — Subagents configured in your project are available to workers.
  • AGENTS.md — Workers follow your project conventions and coding standards.

Headless mission execution

Missions can also run non-interactively via droid exec --mission. This is useful for CI, scheduled jobs, and any environment where you want the orchestrator to plan and execute without a live TUI.
droid exec --mission -f mission.md
You can override the models and reasoning effort used by the orchestrator’s worker and validator agents:
droid exec --mission \
  --worker-model claude-sonnet-4-6 \
  --worker-reasoning-effort medium \
  --validator-model claude-opus-4-7 \
  --validator-reasoning-effort high \
  -f mission.md
FlagDescription
--missionRun droid exec in mission mode (multi-agent orchestration).
--worker-model <id>Model used for mission worker agents.
--worker-reasoning-effort <level>Reasoning effort for mission worker agents.
--validator-model <id>Model used for mission validator agents.
--validator-reasoning-effort <level>Reasoning effort for mission validator agents.
See droid exec for the full headless reference.

Configuration

Missions are tuned through the missionModelSettings object and a few top-level keys. Set these in your global or project settings file.
SettingDescription
missionModelSettings.workerModelDefault model used by mission worker subagents.
missionModelSettings.workerReasoningEffortReasoning effort for mission workers (off, none, low, medium, high).
missionModelSettings.validationWorkerModelModel used by validation workers (scrutiny and user-testing).
missionModelSettings.validationWorkerReasoningEffortReasoning effort for validation workers.
missionModelSettings.skipScrutinySkip scrutiny validation milestones during missions.
missionModelSettings.skipUserTestingSkip user-testing validation milestones during missions.
missionOrchestratorModelModel used by the mission orchestrator.
missionOrchestratorReasoningEffortReasoning effort for the mission orchestrator.
keepSystemAwakeDuringMissionsPrevent the OS from sleeping while a mission is running. Defaults to true.
Pairing a strong orchestrator model with a faster worker model is a common cost-quality tradeoff: planning and validation benefit most from extra reasoning, while routine worker tasks can use a lighter model.

Enterprise: restricting mission access

Organizations can restrict who is allowed to launch missions through the missionPolicy org-level setting:
{
  "missionPolicy": {
    "restrictedAccess": true,
    "allowedUserIds": ["user_123", "user_456"]
  }
}
When restrictedAccess is true, only members listed in allowedUserIds can start new missions. See the settings reference for the full enterprise policy surface.

See also