sources/factory-missions-breakout.md

Summary

This breakout presents Factory's Missions as a planning-first orchestration system for long-running autonomous coding. The durable signal is not "many agents in parallel" by itself; it is a tighter loop of collaborative planning, milestone-based validation, fresh worker contexts, role-specific model/tool assignment, and human project-manager intervention when the system drifts.

Key points

  • Missions are framed as an orchestrated alternative to a single long-lived coding session whose context degrades over time.
  • The system decomposes work into milestones and features, then uses fresh worker sessions per feature instead of asking one agent to hold the whole project in memory.
  • Validation is first-class. Milestones end with review, tests, regression checks, and UI/computer-use verification rather than treating validation as a final cleanup step.
  • Factory explicitly argues for targeted parallelism, not blanket parallel execution. Their claim is that coordination overhead makes broad parallelism less reliable than structured sequential progress with narrow parallel lanes.
  • The planning phase is treated as the highest-leverage step. The product docs repeatedly say execution quality is heavily determined by feature/milestone definition before work starts.
  • Missions are model-agnostic by role: orchestrator, workers, validators, and research agents can use different models rather than forcing one model family across the whole run.
  • The breakout gives a concrete scale claim for one production mission: 16.5 hours, 185 agent runs, 778M tokens, and 89% test coverage.
  • The docs position the user less as a prompt writer and more as a project manager who monitors, redirects, and unblocks the orchestrator.

Why it matters

This is a strong external validation of several ideas already emerging in the wiki:

  • planner/executor separation matters
  • narrow fresh-context workers beat overloaded long-lived sessions
  • validation should happen at milestone boundaries, not only at the end
  • agent systems need an explicit human intervention model, not a fake "fire-and-forget" story
  • the real product surface is the orchestration layer plus harness, not just the base model

The interesting part is where Factory is opinionated: parallelism is useful only when the coordination burden stays low, and long-running reliability comes more from orchestration discipline than from any single-model leap.

Risks and constraints

  • This is partly a product-marketing breakout, so the strongest claims are directional rather than independently verified.
  • The 16.5-hour / 185-run / 778M-token example is impressive, but it is a single highlighted mission and may not represent median economics or reliability.
  • The 89% test coverage metric is ambiguous without knowing baseline, test quality, and whether coverage reflects meaningful behavior verification versus mechanical expansion.
  • There is likely survivorship bias: the showcased mission is a success case, while failure distributions and operator burden are less visible.
  • Factory still describes Missions as a research preview and openly admits unresolved questions around correctness, parallelization, recursive orchestration depth, and cost-quality tradeoffs.
  • The model-agnostic story is strategically attractive but operationally harder: model routing, permissions, and validation discipline become more important as role heterogeneity increases.

Implications

For this wiki, the breakout strengthens a specific thesis: reliable autonomous coding is less about "one super-agent" and more about a governed org-chart of roles, milestone gates, and intervention points.

It also suggests an important distinction between two agent products:

  • interactive coding copilots optimize for local velocity inside a single session
  • mission systems optimize for scoped autonomy over long horizons, with explicit orchestration and recovery paths

That distinction deserves to stay prominent in future synthesis and decision pages.

Open questions

  • When does targeted parallelism beat sequential execution in practice, and how should that threshold be decided automatically?
  • What is the right milestone validation frequency for long-running coding work before coordination costs dominate?
  • Which parts of Factory's approach are generalizable to OpenClaw-style environments versus dependent on their tightly integrated product surface?
  • How much operator attention do these systems actually require over multi-hour or multi-day runs?

Sources

  • X post by Theo Luan (https://x.com/droid_35719/status/2042718795509436801) describing the architecture rationale and a 16.5-hour mission breakout.
  • Factory product article: https://factory.ai/news/missions
  • Factory docs: https://docs.factory.ai/cli/features/missions