Factory.ai Logo

Missions Configuration & Reference

Configuration inheritance, headless execution with droid exec --mission, mission settings, and enterprise access policy.

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.

Bash
droid exec --mission -f mission.md

You can override the models and reasoning effort used by the orchestrator's worker and validator agents:

Bash
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 user or project settings file. Organization administrators can also provide model and reasoning defaults through Enterprise Controls.

SettingDescription
missionModelSettings.workerModelDefault model used by mission worker subagents.
missionModelSettings.workerReasoningEffortReasoning effort for mission workers. Options are model-dependent (see /models).
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.

The six mission model and reasoning fields resolve independently with session-default precedence. Org-managed values act as fallbacks for more-local settings. skipScrutiny and skipUserTesting remain user-managed and are not accepted in org-managed settings.

Tip

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:

JSON
{
  "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.

Related resources

Droid Exec (Headless)

Run missions non-interactively with droid exec --mission.

Enterprise Controls & Managed Settings

Govern mission access and model policy at the organization level.