Factory Missions
Use Factory Missions to plan and execute large, multi-feature projects with structured orchestration. Describe your goal, collaborate on the plan, and let Droid manage the work.
What Missions do
Factory Missions are structured workflows for taking on large, multi-feature work with Droid. Instead of tackling everything in a single session, you collaborate with Droid upfront to build a plan (features, milestones, and the skills needed to accomplish each part), then hand off execution to an orchestration layer that manages the work.
Access Missions with the /missions command (also available via /mission).
Factory Missions are the orchestration feature. Mission Mode is the session state Droid enters after you approve a mission plan; see Interaction Modes for how Mission Mode relates to Normal and Spec modes.
Work with Droid to define features, milestones, and success criteria before any code is written.
Droid reuses your existing skills and develops new specialized skills for each part of the work.
Mission Control manages execution across agents, tracking progress through your plan.
MCP integrations, skills, hooks, and custom droids all work inside Missions.
For optimal outcomes
For the best results, your repository should be at Agent Readiness Level 4 (Optimized) or above.
As a mission works, it runs user-facing QA testing against your application to validate each feature and self-correct as it goes. For this to work in an existing project, your codebase needs an automated, scriptable way to exercise the app the way a user would (for example, a script to stand up or mock all dependencies of the app to simulate all potential user flows). Without it, the mission cannot reliably verify its own work.
Not there yet? Re-run your readiness evaluation with /readiness-report, then close the gaps with /readiness-fix.
How it works
- 1Enter Missions
Start by running
/missionsin any Droid session. - 2Collaborate on the plan
Droid interacts with you back and forth to understand your goal. It asks clarifying questions, probes for constraints, and works with you to define what you actually want built. This is a conversation, not a one-shot prompt.
- 3Build features and milestones
Based on the conversation, Droid constructs a structured plan: a set of features organized into milestones. Each milestone represents a meaningful checkpoint in the work.
- 4Skills are reused or developed
Droid pulls in your existing skills where they apply, and develops specialized skills for parts of the work that need them. This means the execution is tailored to your project and workflow, not generic.
- 5Enter Mission Control
Once the plan is approved, Droid enters Mission Control, the Missions orchestration view that manages execution of the plan. You can monitor progress, see which features are being worked on, and intervene when needed.
For details on getting the plan right, see Planning & Validation. To run and steer an approved mission, see Running in the CLI or Running in the Factory App.
What Missions are good for
We have built and tested Missions across a range of work:
- Full-stack development: Building complete applications with frontend, backend, database, and deployment.
- Research: Deep investigation tasks that require exploring multiple approaches, synthesizing findings, and producing structured output.
- Brownfield migrations: Modernizing existing codebases, swapping frameworks, or restructuring large projects while preserving existing behavior.
- Ambitious prototypes: Product experiments that need to be functional, not just sketched out.
The common thread: work that benefits from upfront planning and structured decomposition rather than ad-hoc prompting.
Open questions
Missions are still evolving. There are fundamental questions we are working through:
- Is parallelization necessary? Running multiple agents in parallel sounds good in theory, but does it actually produce better results than sequential execution? We are testing this.
- How do you maximize correctness? Long-running plans accumulate errors. What validation and correction strategies work best at each stage?
- Cost vs. quality tradeoffs: How aggressive should the orchestrator be? More planning and validation means higher cost but potentially better output. Where is the right balance?
We want your feedback on these. Use Missions, push the workflow hard, and tell us what works and what does not.
Troubleshooting
Missions are not fire-and-forget. The orchestrator is an agent, and you can talk to it. When something goes wrong, pause the orchestrator, describe what you are seeing in plain language, and ask it to recover.