AI Software Factory and Mission Control
Establish the factory's governing idea and separate it from a coding assistant, coding agent, or generic agent platform.
A focused view of boundaries, contracts, state, authority, failure paths, and tradeoffs drawn from this chapter.
3. Operating model
The factory separates the lifecycle into explicit authority and evidence boundaries:
The control plane decides whether work is allowed, records authoritative state, and evaluates the evidence required for progression. The execution plane performs work through agents and tools. An external system such as GitHub Actions or Argo CD may execute deployment, but the factory should govern the decision, policy, evidence, and approval.
4. Canonical domain model
The complete conceptual hierarchy is:
Company -> Workspace -> Repository -> Factory Configuration -> Mission -> Approved Plan -> WorkOrder -> Task -> Attempt -> Evidence -> Pull Request -> Release
The central delivery chain is shorter:
Mission -> WorkOrder -> Task -> Attempt -> Evidence -> Pull Request -> Release
A Mission states the governed outcome. A Plan translates intent into a versioned execution contract. Plan approval authorizes exact work; it does not dispatch an agent or approve a merge. A WorkOrder defines a bounded unit of authority and acceptance. Tasks organize execution. Attempts preserve each immutable try. Evidence supports or refutes acceptance criteria. Pull requests and releases remain distinct governed outcomes.
This separation prevents optimistic state propagation. A successful Attempt does not make a Task accepted. A completed Task does not accept a WorkOrder. A merged pull request does not prove production value.
5. Current Mission Control Implementation
This assessment is grounded at Mission Control commit
8014d5af427b43ff5c5a63cfdf82ec92742c208c.
Mission Control describes itself as the operating system for human-directed, agent-executed software development. Its V1 product promise is deliberately narrow: a human defines an outcome, approves a plan, permits governed execution, and receives a validated, review-ready pull request.
The current architecture uses:
| Layer | Mission Control choice | Responsibility |
|---|---|---|
| Operator interface | React, TypeScript, Vite | Intent capture, approvals, exceptions, evidence, and review |
| Authoritative control plane | Convex | Durable domain state, queries, mutations, actions, authorization, and audit records |
| Orchestration service | Hono on Node.js | Long-running coordination, runtime integration, and external control boundaries |
| Execution runtime | Workflow executor and adapters | Bounded Tasks, Attempts, tools, worktrees, and receipts |
| Repository boundary | Git worktrees and GitHub integration | Isolated changes, commits, pull requests, and source lineage |
Convex remains the source of truth. The Hono service must not create a competing state store. The React UI is an operator surface, not the authority boundary; server-owned commands must enforce policy and lifecycle rules regardless of the caller.
The schema and product contracts include Missions, versioned plans, WorkOrders, workflow runs, approval decisions, verification receipts, immutable lifecycle history, and explicit acceptance rules. Mission Control also defines separate worker and validator responsibilities. Missing, failed, stale, or unknown evidence blocks acceptance.
These mechanisms do not by themselves prove the complete V1 promise. The strongest proof remains a browser-operated golden path against a real controlled repository, including failure, recovery, independent validation, exact GitHub lineage, and a complete review package.
Review this chapter.
Challenge a claim, boundary, missing failure mode, unclear term, or unsupported evidence statement.
- Claim
- Boundary
- Failure
- Evidence