Multi-agent systems work better when delegation, verification, shared state, and negotiation are combined into a workflow with distinct roles.
2
Missions run implementation serially, use adversarial validators, and preserve context through written handoffs and milestone checkpoints.
3
A model-agnostic design lets teams assign different models to planning, implementation, and validation, so the system can improve as models improve.
Summary
Luke Alvoeiro argues that human attention, rather than model intelligence, is now the limit on software production. Factory's Missions system addresses this with an orchestrator that plans work, workers that implement features, and validators that check both code and live behavior. Plans include validation contracts written before implementation, while workers leave structured handoffs with commands, exit codes, unfinished work, and discovered issues. Missions execute features serially because parallel workers often conflict, duplicate work, or make inconsistent architectural choices. Read-only work can still run in parallel. Alvoeiro also argues for choosing models by role, since planning, coding, and validation reward different capabilities. In Factory's Slack clone example, validation generated follow-up work, tests made up half the final code, and prompt caching helped manage cost. The architecture keeps orchestration mostly in prompts and skills, allowing it to benefit from future model improvements.
Human attention is the current limit on software throughput
Alvoeiro says the bottleneck in software engineering is no longer intelligence, but human attention. Even strong engineers can move only a few tasks forward each day because every task needs supervision and every commit needs review. A backlog might contain 50 features, while a person can drive only a couple of them at once. His proposed arrangement is for a human to decide what to build, then let an agent system handle execution for hours or days. The point of multi-agent work is therefore to expand the number of active work streams without requiring a person to supervise every step continuously.
Five communication patterns cover the main multi-agent designs
Alvoeiro groups frontier multi-agent systems into five patterns. Delegation has one agent spawn another for a subtask. Creator-verifier separates implementation from checking, giving the reviewer fresh context and less attachment to the original solution. Direct communication lets agents message one another without a coordinator, but state can fragment. Negotiation handles agents competing or cooperating over shared resources such as an API or part of a codebase. Broadcast sends shared constraints, updates, or context to many agents and helps long-running work remain coherent.
Missions combine four patterns around three separate roles
Missions combine delegation, creator-verifier, broadcast, and negotiation into one workflow. A user describes a goal, discusses its scope, approves a plan, and leaves the system to execute. The system is an ecosystem of agents with shared state and structured handoffs, rather than one long agent session. The orchestrator asks clarifying questions and creates a plan with features, milestones, and a validation contract. Workers receive clean context for implementation and commit their changes. Validators check the result. They run ordinary checks such as tests, types, and lint, then also inspect whether the application works from end to end.
Validation contracts define correctness before implementation begins
The validation contract is written during planning, before code exists. It defines correctness independently of the implementation, sometimes through hundreds of assertions, with each feature assigned the assertions it must satisfy. Alvoeiro says tests written after implementation often reflect the code's decisions rather than the intended behavior, so passing tests can still leave a system wrong. Missions use a scrutiny validator for test suites, type checks, lint, and separate code reviews. A user-testing validator starts the application and interacts with it through computer use, filling forms, checking rendered pages, clicking buttons, and testing complete flows. Both validators begin without prior investment in the code.
Structured handoffs keep long missions from losing context
A worker's handoff records what it completed, what remains unfinished, which commands it ran, the commands' exit codes, discovered issues, and whether it followed the orchestrator's procedures. This written record gives later agents usable context instead of relying on memory across sessions. At milestone boundaries, the system catches errors, scopes corrective work, and pulls the mission back on track. Alvoeiro reports that the longest mission ran for 16 days, longer than a full sprint, and says the structure is what makes that duration possible. Mission control exposes the active worker, handoff summaries, validator findings, and the planned course correction.
Serial feature execution reduces coordination errors
Missions run features serially because parallel software agents often step on one another's changes, duplicate work, or make conflicting architectural choices. The coordination cost can consume the apparent speed benefit while also using more tokens. Only one worker or validator runs at a time for the main feature flow. The system still parallelizes read-only activities, such as searching the codebase, researching APIs, and some code reviews inside validation. Alvoeiro says serial execution looks slower on paper, but the lower error rate compounds over tasks that run for many days.
Alvoeiro says planning benefits from slow, careful reasoning, implementation from fast coding fluency and creativity, and validation from precise instruction following. He calls the skill of assigning models to these seats 'droid whispering'. It involves understanding where different language models fail and how those failures accumulate during a multi-day run. A separate provider can handle validation to reduce bias from shared training data. A model-agnostic architecture avoids being limited by one provider's weakest capability. The same structure can also let open-weight models perform well because contracts and milestone checkpoints supply discipline.
Production results show validation creates follow-up work
In Factory's example of building a Slack clone, Alvoeiro says 60% of time and 60% of tokens went to implementation. Validation did not succeed on the first attempt, so the mission repeatedly created follow-up features through its quality-assurance loop. At the end, tests made up 50% of the lines of code, and those tests covered 90% of the code. Factory also used prompt caching to offset the cost of a long-running task. The example supports his claim that validation must be able to send work back into implementation rather than simply approve or reject the first result.
Prompt-driven orchestration can improve with future models
Factory designed Missions so a new model release would improve the system rather than make its architecture obsolete. Most orchestration behavior lives in prompts and skills instead of a hard-coded state machine. Alvoeiro says the feature decomposition and failure-handling logic takes about 700 lines of text, and changing four sentences can alter execution substantially. Worker behavior comes from skills defined for each mission. Deterministic code stays thin and handles bookkeeping, validation, and blocking progress when handoff problems remain unresolved. The architecture supplies discipline while models supply reasoning and implementation.
