The orchestrator-worker pattern is brilliant for this problem space. It mirrors distributed computing principles - instead of cramming everything into one massive context that degrades over time, you get:

1. *Context locality*: Each worker starts fresh with only relevant context for its specific milestone. No token waste on irrelevant conversation history.

2. *Failure isolation*: If one worker fails or hallucinates, it doesn't corrupt the entire multi-day effort. The orchestrator can retry that specific milestone.

3. *Parallel execution*: Multiple workers can theoretically tackle independent milestones simultaneously, rather than the sequential bottleneck of single-agent approaches.

4. *State checkpointing*: Each milestone completion creates a natural checkpoint. Much easier to resume or backtrack than unwinding a single massive context.

The real challenge is the orchestrator's planning capability - it needs to decompose requirements into truly independent, well-scoped chunks. Poor decomposition leads to workers with insufficient context or conflicting assumptions.

Curious about their approach to cross-milestone dependencies and how they handle cases where early milestones need revision based on later discoveries.

Factory just shipped Missions, their take on long-horizon software agents. Rather than trying to stretch a single context window across a multi-day project, they use an orchestrator-worker model: a planner breaks the goal into milestones, then spins up fresh worker sessions per feature, each with a clean context and a specific scope.