Missions
Missions is a multi-agent autonomous task execution system introduced by Factory. Users describe a goal, after which an orchestrator, workers, and a validator collaborate to complete software tasks autonomously over extended periods. The system distributes work among specialized agents rather than relying on a single agent, and incorporates a validation role to check the results produced by the working agents.
Timeline (last 90 days)
Factory's Missions system ran continuously for up to 16 days.
Missions' verifiers are adversarial by design, and neither type of verifier has seen the code.
Missions requires the Worker to fill in a structured handoff after completing a feature, recording what was done, what was left over, the commands executed and their exit codes, problems found, and whether procedures were followed.
Factory tried having Agents execute software engineering tasks in parallel, but it didn't work, because Agents stepped on each other's changes, duplicated work, and made inconsistent architectural decisions, with coordination overhead eating up the speed gains.
Missions executes serially at the feature level, with only one Worker or Validator running at any given moment; read-only operations within a feature are parallelized.
In Factory's Slack clone production case, 60% of the time and 60% of the tokens were spent on implementation, 50% of the final lines of code were tests, and the tests covered 90% of the code.
Missions writes almost all orchestration logic into prompts and skills rather than a hardcoded state machine, about 700 lines of text, and changing four sentences can significantly change the execution strategy.
Missions' deterministic logic is very thin, responsible only for bookkeeping: running verification and blocking progress when handoff issues remain unresolved.
Luke suggests users open OpenDroid, run slash missions, argue scope with the orchestrator, approve the plan, and then go do something else.
All Facts (14)
Missions系统使用验证合约（Validation Contract）在任何代码编写之前就定义完成的含义
95%UnverifiedMissions将委派、创建者-验证者、广播和协商四种模式组合成一个统一工作流
95%UnverifiedMissions架构由三个角色组成：编排器（规划层）、工作者（实现层）和验证器（质量保障层）
95%UnverifiedMissions的验证器不仅验证代码的lint、类型检查和测试，还验证端到端的行为
90%UnverifiedMissions中每个工作者拥有干净的上下文，通过Git提交让下一个工作者继承干净的代码库
90%UnverifiedMissions executes serially at the feature level, with only one Worker or Validator running at any given moment; read-only operations within a feature are parallelized.
50%UnverifiedIn Factory's Slack clone production case, 60% of the time and 60% of the tokens were spent on implementation, 50% of the final lines of code were tests, and the tests covered 90% of the code.
50%UnverifiedMissions writes almost all orchestration logic into prompts and skills rather than a hardcoded state machine, about 700 lines of text, and changing four sentences can significantly change the execution strategy.
50%UnverifiedMissions' deterministic logic is very thin, responsible only for bookkeeping: running verification and blocking progress when handoff issues remain unresolved.
50%UnverifiedLuke suggests users open OpenDroid, run slash missions, argue scope with the orchestrator, approve the plan, and then go do something else.
50%UnverifiedFactory's Missions system ran continuously for up to 16 days.
50%UnverifiedMissions' verifiers are adversarial by design, and neither type of verifier has seen the code.
50%UnverifiedMissions requires the Worker to fill in a structured handoff after completing a feature, recording what was done, what was left over, the commands executed and their exit codes, problems found, and whether procedures were followed.
50%UnverifiedFactory tried having Agents execute software engineering tasks in parallel, but it didn't work, because Agents stepped on each other's changes, duplicated work, and made inconsistent architectural decisions, with coordination overhead eating up the speed gains.
50%