Factory Missions Architecture Deep Dive: How a Multi-Agent System Runs Continuously for 16 Days

The Core Problem: Human Attention Is the Real Bottleneck in Software Engineering

At the AI Engineer conference, Luke, head of Factory's core agent engine, shared their multi-agent system called Missions. Luke previously created Goose, an open-source programming agent at Block. Now he presents a key insight: The bottleneck in modern software engineering isn't intelligence—it's human attention.

This insight has deep roots in cognitive science. Psychological research shows that human working memory capacity is extremely limited (Miller's Law suggests approximately 7±2 information chunks), and task switching incurs significant "switching costs"—each context switch takes an average of 23 minutes to fully regain focus. In software engineering, this means an engineer's effective concurrent task count rarely exceeds 3-5. Meanwhile, modern LLMs have demonstrated capabilities approaching or surpassing junior engineers in code generation, debugging, and architecture design, making "intellectual resources" no longer scarce while "supervisory bandwidth" becomes the true limiting factor. This shift is analogous to the transition from human labor to mechanical power during the Industrial Revolution—not replacing human judgment, but liberating humans from the execution layer to the decision layer.

Even the best engineers can only push forward a few tasks per day. A backlog of 50 feature requests that current models are fully capable of handling remains stuck due to insufficient human bandwidth for oversight. Factory's vision: humans decide what to build, and the system figures out how to implement it—agents can work continuously for hours or even days, and the work is done when you come back.

Five Multi-Agent Collaboration Patterns

Luke proposed a concise taxonomy that categorizes multi-agent frameworks into five fundamental patterns. These five patterns correspond to classic communication topologies from distributed systems and organizational theory, essentially representing tradeoffs between communication overhead, state consistency, and concurrency efficiency—highly isomorphic to the challenges faced by the CAP theorem in distributed systems:

1. Delegation: One agent spawns another sub-agent, corresponding to a tree-shaped hierarchical structure—the lowest communication overhead form of multi-agent communication
2. Creator-Verifier: One agent builds, another checks. Derived from the "Four-Eyes Principle" in software engineering, it eliminates confirmation bias through role separation and avoids sunk cost bias via separation of concerns
3. Direct Communication: Direct conversation between agents without a central coordinator, corresponding to peer-to-peer networks—flexible but prone to state fragmentation
4. Negotiation: Agents communicate around shared resources, drawing from Mechanism Design in game theory—best suited for positive-sum games
5. Broadcast: One agent sends information to multiple agents, similar to Pub/Sub architecture—critical for maintaining consistency in long-running tasks

Missions Architecture Design: A Three-Role Collaboration System

Missions combines four patterns—delegation, creator-verifier, broadcast, and negotiation—into a unified workflow. You describe the goal, refine scope through conversation, approve the plan, and the system handles hours or days of execution.

Orchestrator: The Planning Layer

The orchestrator acts as your strategic advisor—asking the right questions, checking for ambiguities in requirements, and ultimately producing a plan that includes features, milestones, and a Validation Contract. The validation contract defines what "done" means before any code is written—this is the critical design element of the entire system.

Workers: The Implementation Layer

Each worker starts with a clean context—no accumulated baggage or degraded attention. Workers read the specification, implement features, commit via Git, and let the next worker inherit a clean codebase.

Validators: The Quality Assurance Layer

Most systems validate through linting, type checking, and tests. Missions does all of that, plus validates behavior—not just asking "does the code look correct?" but "does this work end-to-end?"

The Validation Contract Mechanism: The Engineering Wisdom of Writing Assertions Before Code

The validation contract design philosophy draws deeply from two engineering traditions: Test-Driven Development (TDD) and Design by Contract. TDD was systematized by Kent Beck in Extreme Programming (XP), with its core "Red-Green-Refactor" cycle—write a failing test first, then write the minimal implementation to make it pass, then refactor. Design by Contract was proposed by Bertrand Meyer in the Eiffel language, formally defining component behavior through preconditions, postconditions, and invariants.

In the traditional pattern, an agent writes code and then writes tests. Tests pass, coverage is met, but the tests are "shaped" by the code—they confirm decisions rather than catch defects. This is the core problem with AI code generation: models tend to generate tests that "look reasonable" rather than tests that "catch real defects," because the latter requires a perspective independent of the implementation. Relying on such validation means the system will eventually drift.

The validation contract is written during the planning phase, defining correctness independently of implementation. It advances both of these ideas into the multi-agent scenario: it's not just a test, but a formal definition of "done"—pushing these two traditions forward into multi-agent contexts.