How Missions Work (5 min read)

Missions stabilizes long-horizon autonomous work not by cramming a broad, complex task into a single context, but by splitting it so that new agents each take on only a narrow goal. The core premise is that agents are highly sensitive to their own context.

As context grows longer, two problems get worse.

• Irrelevant context accumulation: information unrelated to the current goal piles up, degrading the signal-to-noise ratio.
• Adversarial context accumulation: when the party that implemented the work also evaluates it, objectivity breaks down because it gets pulled toward its existing judgments.

So the system separates roles. The Orchestrator handles planning, decomposition, progress management, and final completion; Workers implement clearly specified features; and Validators check completeness using a separate, fresh context. The design avoids having a single agent carry both implementation and evaluation together, and validation is always handled by an independent party.

This philosophy leads to a design that applies test-driven development at two levels.

• Workers write tests before writing code.
• At the mission level, a validation contract is created before the feature definition.

This ordering matters because if the implementation is created first, the validation criteria end up getting pulled toward that implementation. The validation contract is checked against black-box criteria—the way actual users would use the product—not an evaluation that looks inside the code.

State is likewise not concentrated in a single agent. It's distributed across shared artifacts such as the feature list, research notes, operating rules, and a knowledge base, and each agent reads only what it needs right now. Model characteristics are matched to this as well: strong models for planning and judgment, cost-efficient models for execution, and careful, critical models for validation.

The execution flow is relatively clear. After organizing user requirements, a validation contract is created, and features are split into milestones. A runner sequentially executes workers per feature, and once a milestone is finished, a fresh validator checks it. If issues come up, the orchestrator creates a fix feature and reruns it, repeating until it passes.

As a real example, there was a mission that built a Slack clone. It ran for a total of 16.5 hours, with orchestration taking 0.38 hours (2.3%), implementation taking 9.98 hours (60.5%), and validation taking 6.14 hours (37.2%). In total, 185 runs were executed, generating 778.5M tokens and 38.8k lines of code, of which 52.5% were tests, with statement coverage at 89.25%.

The validation loop also operated continuously. 6 milestones converged within 2 to 4 validation rounds, and out of 81 issues found by the validator, 21 fix features were generated. That ratio, compared to 61 implementation features, comes to 34.4%—a structure that ran validation and fixes considerably more than plain implementation.

In the end, Missions is the first version to close the loop in software development. As models get better, more sophisticated specs, fewer mistakes, and more reliable validation become possible; and as models get faster and cheaper, more validation rounds can be run. Currently, you can get started by running /missions in a Droid session.