The Multi-Agent Architecture That Actually Ships — Luke Alvoeiro, Factory

Luke Alvoeiro frames modern software development as a problem of human attention, not simply model intelligence. Engineers may face dozens of potential features but can advance only a handful because implementation, supervision, and review all compete for their time. The architectural question is whether a person can specify what should be built while an agent system determines how to execute it over extended periods. 0:15

To organize the fragmented landscape of multi-agent systems, Alvoeiro identifies five interaction patterns. Delegation lets one agent assign work to another; creator-verifier separates implementation from independent review; direct communication enables agent-to-agent exchanges without a central coordinator; negotiation coordinates access to shared resources; and broadcast distributes information or constraints across a group. Each pattern addresses a different coordination problem. 1:17

These patterns carry different tradeoffs. Direct communication can fragment state when no coordinator maintains a single source of truth, while negotiation can produce mutually beneficial coordination rather than adversarial competition. Factory’s Missions combines delegation, creator-verifier, negotiation, and broadcast into a workflow in which a person discusses scope, approves a plan, and then allows the system to handle extended execution. 2:22

A mission is not one uninterrupted agent conversation. It is an ecosystem of agents linked by shared state and structured handoffs, with three distinct roles: orchestrator, worker, and validator. The orchestrator clarifies requirements, asks strategic questions, and produces a plan containing features, milestones, and a validation contract that establishes what completion means before implementation begins. 4:27

Workers implement individual features with clean context rather than carrying the accumulated history and degraded attention of a single prolonged session. Each worker reads its specification, makes the required changes, and commits through Git, allowing the next worker to begin from a working codebase without inheriting the previous agent’s full conversational baggage. 4:27

Validators remain separate from the agents that created the implementation. Beyond conventional linting, type checking, testing, and code review, they examine whether the software actually works end to end. This separation is designed to reduce the bias of an implementation agent evaluating its own decisions and to prevent a long-running mission from drifting away from its intended behavior. 2:22

The central safeguard is the validation contract, written during planning before any implementation exists. Alvoeiro argues that tests written after code can mirror the choices already embedded in that implementation instead of independently checking its intended purpose. By specifying correctness first, the mission gives later validators a standard that does not originate from the code they are evaluating. 5:34

A complex project may require hundreds of assertions, with every feature assigned one or more assertions and the complete feature set collectively covering the contract. At each milestone, a scrutiny validator runs the test suite, type checks, linting, and dedicated code-review agents for completed features. A separate user testing validator launches the application and exercises practical flows by interacting with forms, rendered pages, buttons, and other application behavior. 6:42

Behavioral validation has a significant cost: interacting with a live application takes longer than conventional scrutiny, and Alvoeiro reports that much of a mission’s wall-clock time can be spent waiting for real-world execution rather than generating tokens. The benefit is independent, adversarial verification by agents that have not previously seen the implementation and are not invested in defending it. 7:38

When work fails validation, the system relies on structured handoffs rather than agent memory. Workers record completed and unfinished work, executed commands and their exit codes, discovered issues, and compliance with orchestrator-defined procedures. Milestone boundaries then become opportunities to identify errors, scope corrective features, and return execution to the original plan. 7:38

Alvoeiro challenges the assumption that adding more simultaneously active agents automatically increases software-delivery throughput. Factory found that concurrent implementation agents could overwrite or conflict with one another’s changes, duplicate work, and make incompatible architectural decisions. In that setting, coordination overhead consumed the expected speed gains while also increasing token expenditure. 8:43

Missions therefore executes features serially, with only one worker or validator active at a time. Parallelism is reserved for read-only operations inside a feature or validation step, such as searching a codebase, researching APIs, or conducting independent code reviews. Although this can appear slower in a simplified throughput calculation, Alvoeiro argues that fewer errors compound into an advantage across tasks lasting many days. 9:50

Because extended autonomous execution cannot be understood effectively through a conventional chat transcript alone, Factory built Mission Control as a dedicated operational view. It exposes project progress, budget consumption, the currently active worker, and handoff summaries describing discoveries and course corrections. The interface supports both active oversight and asynchronous supervision without requiring a human to monitor every implementation step. 9:50

The architecture has demonstrated extended duration, but its boundaries remain explicit. Alvoeiro says Factory’s longest mission ran for 16 days and expresses a belief that missions could reach 30 days; the latter is presented as an expectation, not an observed result. He also identifies greater workload parallelization and orchestration across multiple missions as unresolved questions. 8:43

The three roles impose different demands on underlying models. Planning benefits from careful reasoning, implementation from fast coding fluency and creativity, and validation from precise instruction following. Alvoeiro describes the emerging operational skill of choosing among these capabilities as Droid whispering: understanding how different models behave, where they fail, and how those failures interact across a multi-day workflow. 10:45

A model-agnostic architecture allows different models or providers to occupy different roles, including using a separate provider for validation to reduce the risk of shared biases. Conversely, validation contracts and milestone checkpoints can compensate for less capable individual models, which Alvoeiro says allows missions to run successfully even with open weight models. His argument is not that any model works equally well, but that system structure and deliberate role assignment can improve reliability. 11:42

In an example involving a Slack clone, Alvoeiro reports that implementation accounted for 60% of time and 60% of tokens, validation did not succeed on the first attempt, and follow-up features were needed. He also describes a final codebase in which approximately 50% of lines were tests and 90% of code was covered by those tests, with prompt caching used to mitigate the cost of long-running execution. These figures describe the presented example rather than a guaranteed outcome for every mission. 12:45

To avoid making the architecture obsolete when models improve, Factory places most orchestration behavior in prompts and skills rather than a rigid hard-coded state machine. Alvoeiro describes roughly 700 lines of text governing feature decomposition and failure handling, mission-specific worker skills, and a thin deterministic layer responsible for bookkeeping, validation, and blocking progress when handoff issues remain unresolved. The intended division is straightforward: the system supplies operational discipline while models supply adaptable intelligence. 14:00