Factory AI "Missions" — Deep Research

Researched 2026-08-02 across six parallel sweeps: official docs, Factory news/blog, npm + GitHub artifacts, a full reverse-engineered prompt capture, community/international coverage, founder interviews, and competitor responses. Every claim cites its source. Factory self-reported numbers are flagged; nothing below has been independently benchmarked.

TL;DR

Missions is Factory's multi-agent orchestration mode for its Droid agent: describe a large goal, collaborate on a plan (features grouped into milestones), approve it, and an orchestrator dispatches fresh-context worker agents (one per feature, serially) with independent scrutiny + user-testing validators injected at every milestone, until a pre-written validation contract passes. Runs hours to days (median ~2h; recorded max 16 days; Factory believes 30 is achievable). It is not a cloud service — it's an orchestration loop inside the droid binary, runnable locally, headless in CI, or async on "Droid Computer" remote machines (E2B or BYOM). Launched Feb 26, 2026 (research preview, Enterprise + Max); GA to all users ~late March 2026; extended to Web/Desktop + async delegation June 2026 ("Factory 2.0"). The architecture is unusually verification-centric — validators never see the implementers' reasoning — and the whole company thesis hangs on it: "If you can frame any problem as the set of verification systems that need to validate it, then you can solve that problem with AI today" (CTO Eno Reyes).

---

1. What Missions is

• Verbatim: "Use Factory Missions to plan and execute large, multi-feature projects with structured orchestration. Describe your goal, collaborate on the plan, and let Droid manage the work." (docs: overview)
• Launch framing: describe a business outcome; approve scope; a hierarchy of Droids plans, executes, validates over multi-day horizons without continuous oversight. (Introducing Missions)
• Motivating thesis (Factory eng talk, AI Engineer, May 2026): "The bottleneck in software engineering nowadays is not intelligence. It's limited by human attention." (talk summary)
• Docs capabilities: Collaborative Planning, Skill-Aware Execution, Structured Orchestration (Mission Control), Config Carries Over (MCP, skills, hooks, custom droids, AGENTS.md). (docs: overview)
• Use cases: full-stack builds, research, brownfield migrations, ambitious prototypes — "work that benefits from upfront planning and structured decomposition rather than ad-hoc prompting." (docs: overview) Reyes: generalizes to research writing and ML training. (LinkedIn)

Terminology

Term	Meaning	Source
Droid	Factory's agent (CLI, desktop, web/mobile)	docs
Mission	Orchestrated project unit: features + milestones plan	docs: overview
Mission Mode	"Session state Droid enters after you approve a mission plan"; Sessions-API interactionMode: auto|spec|agi|mission	docs, API
Mission Control	Orchestration dashboard (terminal UI in CLI; visual at app.factory.ai/missions)	docs: running-app
Orchestrator	Top-level agent; conversable; never writes code	docs, gist
Worker	Fresh-context subagent, one feature at a time	docs: reference
Validator	Milestone-end agents: "scrutiny" + "user-testing"	docs: reference
Validation contract	Testable behavioral assertions written before any code	missions-architecture

2. Timeline

Date	Event	Source
Apr 2023	Factory founded (Matan Grinberg CEO, Eno Reyes CTO); early "journey in the desert" incl. returning ~$2M customer revenue	Training Data Jul 2026
Jun 2024	"Code Droid" SWE-bench report (19.27% SWE-bench Full, then-SOTA claim)	factory.ai/news
Sep 26, 2025	Droid CLI launch; Series B $50M same month (NEA, Sequoia, J.P. Morgan, Nvidia)	Training Data, HN
Jan 20, 2026	Agent Readiness framework (8 pillars, 5 levels, 60+ binary LLM-evaluated criteria) — becomes the Missions prerequisite	agent-readiness
Jan 28, 2026	Wipro global partnership	Businesswire
Feb 4, 2026	Reyes pre-launch tell: agents managing context across "eight to ten hours of continuous work"	Stack Overflow blog
Feb 26, 2026	Missions launch — research preview, Enterprise + Max, CLI + IDE	Introducing Missions, tweet
Feb 27, 2026	HN launch thread: 3 points, 1 comment	HN
Mar 24–25, 2026	Community mitmproxy capture of full mission prompts (V1ki gist; CLI v0.84.0)	gist
~Late Mar 2026	GA: "Missions are now available to all Factory users"	tweet
Apr 2026	Series C $150M at $1.5B (Khosla-led; Sequoia, Insight, Blackstone, NEA); >$220M total	Menlo Times, 20VC
Apr 10, 2026	"How Missions Work" architecture deep-dive	missions-architecture
Apr 22, 2026	Droid Computers launch (persistent remote machines; async substrate; self-taught "memories and skills")	droid-computers
Apr–May 2026	CLI hardening: enterprise access policy (v0.105), ~/.factory state consolidation (v0.108), schema-validated artifacts + auto-denied worker permission requests (v0.109.1), UTC cron scheduling (v0.109.3), rate-limit pausing (v0.111), settings snapshot at launch (v0.113)	changelog
~May 6, 2026	AI Engineer talk "How Factory Runs Coding Agents for 16 Days Straight" (Luke Alvoeiro)	summary, ZenML writeup
Jun 15, 2026	"Factory 2.0" — Missions on CLI/Web/Desktop + delegation to Droid Computers	software-factory, tweet
Jul 21, 2026	Grinberg "dark factory" episode: 90% of coding tokens async within 12–24 months	Training Data
Jul 2026	Unified Mission side panel (v0.172); orchestrator-interrupt pause fixes (v0.168–0.185); npm droid at v0.186.0 (Jul 31)	changelog, npm

3. Lifecycle and UX

1. Enter via /missions (alias /mission); in the app, Mission Mode at session creation or app.factory.ai/missions. (docs: overview, running-app)
2. Planning is conversational — "This is a conversation, not a one-shot prompt"; Droid probes constraints and pushes back. Docs: "The biggest value we have found in Missions is in the planning phase." (docs: planning) A Factory engineer's summary of the workflow: "Open Droid → Run /missions → Argue with the orchestrator about scope → Approve the plan → Go do something else." (LinkedIn)
3. Approval produces a structured plan (features in milestones + skills) and the session enters Mission Control.
4. User role during execution = project manager: "monitor progress, unblock workers, and redirect"; steer the orchestrator in plain language; it can re-plan, reorder, re-scope mid-mission. (docs: running-cli)
5. App dashboard: time + credits in top bar; per-role model dropdowns switchable live; milestone drill-down to per-feature validation criteria and commits; per-worker terminal output and thought process; pause/re-plan/resume; resume past missions "exactly where you left off." (docs: running-app)
6. Headless/CI: droid exec --mission -f mission.md; requires --auto high or --skip-permissions-unsafe; per-role --worker-model, --worker-reasoning-effort, --validator-model, --validator-reasoning-effort; orchestrator via -m/-r; scheduled missions cron in UTC. (docs: reference, droid-exec)

4. Architecture

Primary sources: How Missions Work (Apr 10, 2026), the AI Engineer talk, docs, and the reverse-engineered prompt (§5).

• Design principle: "Agents are highly reactive to their context." Role separation prevents context dilution and self-evaluation bias; each trajectory has a single goal.
• Orchestrator: decomposes work; writes the validation contract before features exist; delegates deep code reading to subagents to protect its context; never implements; never validates its own plan's output; converts validator findings into targeted fix features.
• Workers: one fresh-context session per feature; tests before code (worker-level TDD); hand off when work appears correct — "final correctness judgment belongs to independent validators." Median 51 turns (p90 123).
• Validators: injected programmatically at milestone end — not by the orchestrator. Scrutiny validators review implementation quality and trajectory integrity; user-testing validators exercise the running system as a black box against the contract, having never seen the code or the implementers' reasoning (adversarial by construction). Median 30 turns (p90 37). They surface issues, never fix them. "Validation never succeeds on first attempt." (AI Engineer talk)
• Two-level TDD: tests-before-code per worker; contract-before-features per mission. "Tests written after implementation don't catch bugs. They confirm decisions." (Alvoeiro)
• Serial execution, by design: features execute one at a time; parallelism only for read-only operations — chosen to avoid coordination errors on multi-day runs. (AI Engineer talk) The launch post's "parallelization within features and during validation" refers to subagent fan-out, not concurrent feature work; docs still list parallelization as an open question.
• Shared state externalized to artifacts, not context: validation-contract.md, features.json, validation-state.json, services.yaml, knowledge library; git as coordination substrate and audit trail.
• Skills capture: "As Missions run, the orchestrator Droid captures patterns from your codebase as reusable skills. Worker Droids refine them on the fly." (tweet)
• Model routing at launch (self-reported): orchestration Claude Opus 4.6; implementation Sonnet/Opus 4.6; validation GPT-5.3-Codex; research Kimi K2.5. All per-role configurable; docs recommend strong orchestrator + faster workers. Grinberg's stated pattern: "generate the code with OpenAI, test it with Anthropic, review it with Gemini." (Introducing Missions, Training Data)

5. Reverse-engineered internals (prompt capture + SDK schemas)

From the V1ki gist (75KB, mitmweb capture of POST api.factory.ai/api/llm/a/v1/messages, CLI v0.84.0, Mar 2026, updated Aug 2026) and Factory-AI/droid-sdk-typescript (src/schemas/mission.ts, Apache-2.0). Point-in-time; prompts may have drifted since v0.84.0.

Orchestrator (51KB mission prompt appended to the 5.4KB generic Droid prompt)

• Identity: "You are the architect and manager of a multi-agent mission... You don't build — you design systems that build, and steer them to success." Hard "CRITICAL: You Do NOT Implement" section.
• Four phases: Mission Planning → Worker Design → Creating Mission Artifacts → Managing Execution. Must begin by invoking server-side skills mission-planning and define-mission-skills simultaneously.
• Context protection: orchestrator keeps only structural overview (READMEs, configs, layouts); all deep code reading delegated to Task subagents.
• Two-directory model: missionDir (from ProposeMission: mission.md, validation-contract.md, validation-state.json, features.json, AGENTS.md) vs repo .factory/ (skills/, services.yaml, init.sh, library/, research/, validation/) which must be committed.
• Artifact ordering ("mission-level TDD"): contract first — per-area subagents plus ≥2 sequential adversarial review passes — then validation-state (all pending), then features.
• Milestones are vertical slices; a passed milestone is "sealed" — features can never be added to it; overflow goes to a follow-up or a misc-* milestone (max 5 features).
• features.json array order = execution order; urgent fixes inserted at top; failed features reset to pending and re-run first.
• fulfills semantics: "completes, not contributes to" — each contract assertion owned by exactly one leaf feature; coverage gate (no orphans/duplicates) before starting.
• StartMissionRun is a blocking call: orchestrator cedes control until a handoff needs action, the user pauses, or all features complete.
• Handoff protocol: on discoveredIssues/whatWasLeftUndone, orchestrator must choose — (A) new feature at top, (B) reset feature with updated description, (C) fold into pending feature, (D) misc-* milestone — or dismiss via DismissHandoffItems with a ≥20-char justification; "low priority/non-blocking is NOT valid."
• Validator injection: milestone completion auto-injects two sequential validation features — scrutiny-validator (test/typecheck/lint hard gate + one review subagent per feature; writes synthesis.json) then user-testing-validator (derives assertions from fulfills, spawns flow-validator subagents, updates validation-state). "Do NOT create these yourself." Validator subagents materialize as personal custom droids (user-testing-flow-validator, scrutiny-feature-reviewer, worker in ~/.factory/droids).
• Overrides allowed but never silent: validator failures can be overridden with recorded justification; unfinished assertions must move to an unsealed milestone.
• End gate: all assertions "passed" + at least one README create/update.
• Infra: worker-spawn failures reference retrying against factoryd — a daemon underlies execution.

Tool lists (exact)

• Orchestrator (17): Read, LS, Execute, Edit, Grep, Glob, Create, AskUser, WebSearch, TodoWrite, FetchUrl, GenerateDroid, Skill, ProposeMission, StartMissionRun, DismissHandoffItems, Task.
• Worker (13): same base minus AskUser, Task, and all three mission tools; plus ExitSpecMode. Workers cannot spawn subagents or ask the user; worker prompt is the generic Exec Mode prompt ("Never prompt the user... do exactly what the user asks, no more, no less"). Lifecycle: system pre-assigns feature → invoke mission-worker-base skill (read mission.md, run init, baseline tests) → invoke the feature's skill → commit → structured handoff.

Schemas (official, from droid-sdk-typescript)

• HandoffSchema: whatWasImplemented, whatWasLeftUndone, verification (commandsRun with exit codes, interactiveChecks), tests added/updated + coverage, discoveredIssues (severity: blocking|non_blocking|suggestion), skillFeedback (deviations from procedure + suggested changes).
• MissionState: awaiting_input | initializing | running | paused | orchestrator_turn | completed. FeatureSuccessState: success|partial|failure.
• MissionPauseReason includes unrecoverable_usage_402 — missions auto-pause on billing exhaustion.
• Features carry system-managed workerSessionIds[]; "CLI/orchestrator owns the canonical on-disk feature shape."
• validation-contract.md assertions: stable IDs (VAL-<AREA>-###, VAL-CROSS-###) with behavioral pass/fail descriptions and evidence requirements (screenshot, console-errors, network assertions).
• services.yaml: install/typecheck/build/test/lint commands + per-service start/stop/healthcheck/port/depends_on; hardcoded ports; test parallelism max(1, floor(cpus/2)).
• Python SDK has mission schemas too (droid-sdk-python/src/droid_sdk/schemas/mission.py).

Discrepancy

The capture observed claude-opus-4-6 (max_tokens 128000) for both orchestrator AND workers — at odds with Factory's stated multi-model routing. Possibly config/plan-dependent; unresolved.

6. Self-QA tooling

• Validation requires the mission to drive the real app. Prereqs: single command starts the stack; logs routed to filesystem (security warning: disk logs can capture secrets/PII); modest resource use; programmatic input path. (docs: planning)
• Default tools shipped: tuistory — "Playwright-like testing for TUI applications," a third-party package by xmorse (remorses/tuistory, 345★) — and agent-browser — "Browser automation CLI for AI agents" by Vercel Labs (39.8k★). Neither is Factory-built. (npm registry, GitHub)
• Consumed via Factory's droid-control plugin (factory-plugins): /demo (records PR demo videos via Remotion), /verify (tests a behavior claim with evidence), /qa-test; skills for tuistory, agent-browser, pty-capture, cua-driver (native desktop). Inferred to be how user-testing validators produce the contract's evidence types (screenshot/console/network); the mission prompt doesn't name the plugin.

7. Execution substrate

• An orchestration loop in the droid binary, not a cloud service. Evidence: keepSystemAwakeDuringMissions (default true), Linux wake-lock changelog fixes, mission state under ~/.factory, full config inheritance, headless droid exec --mission. (Derived; docs, changelog)
• Mission plan = persisted, schema-validated artifact mutated via patches ("create, edit, apply-patch," v0.109.1) → checkpoint/resume without transcript replay.
• Droid Computers (async substrate, Apr 22, 2026): persistent machines keeping filesystem, credentials, services, process memory. Managed = E2B sandboxes (provider: byom|e2b), 4 CPU / 8 GB RAM / 6 GB swap, WebSocket tunnel via daemon (Ed25519 keys, no exposed SSH), pause-when-idle billing. BYOM free; managed on Max/Growth/Enterprise. (news, docs, API)
• Daemon: droid daemon / factoryd, JSON-RPC over WebSocket; transport for Slack, Linear, REST API, Automations; SDK connectDaemon().
• API: no /missions REST endpoint — missions via Sessions API interactionMode: mission or CLI; API-created sessions require computerId.
• Packaging: npm droid/@factory/cli v0.186.0 (Jul 31, 2026, UNLICENSED, near-daily releases) = 25KB installer hard-linking per-platform binaries (@factory/cli-darwin-arm64 ≈ 118.7MB); likely Bun-compiled (Factory maintains bun-pty, forked tui-test). CLI closed-source.
• Adjacent: Factory-AI/vfs — "The filesystem for agents": SQLite-backed virtual FS, copy-on-write sandboxing, FUSE/NFS, SQL-auditable ops, "holds even against prompt-injected agents." Beta; no observed mission integration yet (plausible future worker sandbox).

8. Configuration reference

~/.factory/settings.json (project overrides win; settings.local.json merges last) — docs: reference:

• missionOrchestratorModel / missionOrchestratorReasoningEffort
• missionModelSettings.workerModel / .workerReasoningEffort (off|none|low|medium|high)
• missionModelSettings.validationWorkerModel / .validationWorkerReasoningEffort
• missionModelSettings.skipScrutiny / .skipUserTesting (default false; QA also disableable per-mission)
• keepSystemAwakeDuringMissions (default true)
• Enterprise: missionPolicy: {"restrictedAccess": true, "allowedUserIds": [...]} (v0.105.0)
• Settings snapshotted at launch (v0.113.0); worker permission requests auto-denied (v0.109.1)
• Full config inheritance: MCP servers, skills, hooks, custom droids, AGENTS.md (CLAUDE.md compat; 80k initial / 40k dynamic char caps). (agents-md)
• Community confirmation: DeepSeek's own docs show third parties setting open-weight models as mission worker/validator via missionModelSettings. (deepseek-ai/awesome-deepseek-agent)

9. Prerequisites, cost, limits

• Repo readiness: Agent Readiness "Level 4 (Optimized) or above" recommended; without scriptable app exercise "the mission cannot reliably verify its own work"; remediate via /readiness-report / /readiness-fix. Framework: 8 pillars, 5 levels, 60+ binary LLM-evaluated criteria (variance 7%→0.6% via grounding); benchmarks: CockroachDB L4 (74%), FastAPI L3 (53%), Express L2 (28%). (docs, agent-readiness)
• Cost heuristic: total runs ≈ #features + 2 × #milestones — a floor; fix features add runs (34% of implementation in the flagship example). (docs: planning)
• Billing: same rolling rate limits as sessions; requires Extra Usage enabled; missions pause on rate limit and auto-pause on billing exhaustion (unrecoverable_usage_402). Third-party warning: "If you need a firm token budget guarantee, skip Missions" — mid-mission quota exhaustion is real on Pro/Plus. (docs: pricing, Developers Digest)
• Plans: Pro $20 / Plus $100 / Max $200 per month + Enterprise; launched Enterprise+Max, GA'd to all ~Mar 2026.
• Failure handling: feature retry limit (value unpublished); blocked missions halt and return control; orchestrator interrupts pause the mission.
• Undocumented: max features/workers, retry-limit value, PR-creation flow (dashboard tracks commits; PR automation lives in droid-action / Software Factory).

10. Measured behavior (all Factory self-reported)

• Durations: median ~2h; 65% >1h; 37% >4h; 14% >24h; recorded max 16 days; team "believes 30-day missions are achievable." Interactive sessions median 8 min for contrast. (Introducing Missions, AI Engineer talk)
• Tokens: ~12x a normal session (9x at p99); ~45K tokens/min sustained; 3 msg/min at 19K tokens/msg — wall-clock dominated by builds/tests/browsing, heavy prompt caching.
• Examples: COBOL→Java 33.8h; Rust HTTP benchmark tool 22.3h; memory-leak investigation 24.2h; Tauri+React app 30h.
• Slack-clone flagship: 16.5h (60.5% implementation / 37.2% validation / 2.3% orchestration); 185 agent runs (1 orchestrator + 12 subagents, 63 workers, 27 validators + 82 subagents); 778.5M tokens (744.9M cache reads, 3.4M output); 38.8k LOC — 52.5% tests, 89.25% statement coverage; 6 milestones, ≤4 validation rounds each; 81 issues surfaced (65 blocking). (missions-architecture)
• Reyes (Apr 2026): customers "run missions lasting 14 days straight, with hundreds of agents executing continuously." (Zero Prime)
• Business claim: teams go from ~10 to ~30 concurrent workstreams. (AI Engineer talk)

11. Founder narrative and strategy

• "Dark factory" (Grinberg, Training Data, Jul 21 2026): 90% of coding tokens will run asynchronously within 12–24 months; droids ingest signals (tickets, customer feedback) and produce first-pass fixes without human kickoff. Missions is the vehicle.
• Verification thesis (Reyes, AI Engineer FDE talk, Jul 2026): validation density (linters, types, tests, scans) = "dense reward signal"; primary barrier to autonomy. Factory's own codebase: 15–20% fully autonomous. ~30–40% of customer readiness issues auto-fixable; 60% need workflow/cultural change.
• Open-weight models: <1% of platform tokens at start of 2026 → double-digit % by mid-2026; 80–90% of enterprise coding tasks claimed routable to open-source. (Training Data, 20VC)
• Roadmap: usage-based → outcome-based pricing via competitive task bidding against validation criteria. (Training Data)
• Business: $1.5B valuation, >$220M raised, ~20 engineers at Series C; EY confirmed largest customer; named logos Nvidia, Adobe, Morgan Stanley, MongoDB, Bayer, Zapier, Adyen, Palo Alto Networks (customer-Mission usage stories are all aggregator-sourced, unverified). Enterprise posture: SOC 2 Type II, ISO 27001/42001, RBAC/SSO/SCIM, hybrid/airgapped ("You could run Droid in a submarine"), Droid Shield secret scanning, OpenTelemetry.

12. Competitive landscape (Feb–Aug 2026)

Competitor	Long-horizon feature	Date	Architecture vs Missions
Cognition Devin	Managed Devins: coordinator spawns isolated child Devins (own VMs), monitors, kills underperformers	Mar 19, 2026	Orchestrator + self-validating workers; no independent validator tier. Devin Desktop (Jun 2026) adds cross-vendor orchestration via ACP — something Factory lacks. Cognition itself skeptical of swarms: "Most practical use... has been one single Devin"; "pure auto-merge vibe-coding breaks after ~2 weeks due to codebase entropy" (Latent Space)
OpenAI Codex	Long-horizon tasks: ~25h single run, 13M tokens, 30k LOC via durable markdown memory + milestone checkpoints	2026	Single-agent endurance + file memory; human supervises; no orchestrator/validator hierarchy
Anthropic Claude Code	Agent teams (ex-"Swarms"): lead delegates to teammates, shared task list, inter-agent messaging	Feb 6, 2026 (~3 weeks before Missions)	Lead/teammate ≈ orchestrator/worker; session-scale, no validator role or mission persistence layer
Cursor	Cursor 3 "Glass": Agents Window, background/cloud agents, Composer 2.x	Apr 2, 2026	Parallel-session UI orchestration; no published validator hierarchy or multi-day claims; rhetorically converging ("factories that create software")
Google Jules	Planning Critic (plan-review agent); AgentTeam API (ADK 2.0)	Jan / May 2026	Critic ≈ validator-at-plan-time; queue-based single tasks → PR
GitHub/Microsoft	Agent HQ (Oct 2025) + Copilot desktop control center (Jun 2026)	—	Governance/routing over third-party agents, not an autonomous mission runner
Sourcegraph Amp	Auto-decomposition into parallel subagent branches	2026	No validator tier documented

Distinctive Missions angles (grounded + inference): (a) independent adversarial validator tier bound to a pre-written contract, (b) per-role cross-vendor model routing, (c) multi-day durations as a headline target, (d) repo-readiness framework as an explicit precondition. No third party has benchmarked Missions against any competitor.

13. Reception and independent evidence

• Thin community traction: HN launch thread 3 pts/1 comment; zero indexed Reddit threads on Missions; Factory's own LinkedIn launch post got 38 reactions on 26k followers. Japanese/Korean/Chinese organic coverage minimal.
• Sponsored amplification: the most-viewed YouTube advocate (Ray Fernando, "This AI Agent Made My Code Better the Longer It Ran") is a paid Factory partner distributing free-token promos — treat as promotional. (X)
• Best independent positive: "@0xSero": "I have used every single orchestration tool out there. This is by far the best... It takes some time to get the scope decided but I have walked away for days at a time." Single unverifiable tweet. (X)
• Strongest negative: "Support from hell" (Medium, Dec 2025, pre-Missions): stuck sessions unresolved for ~3 months, support chat removed, accuses Factory of prioritizing influencer marketing over support. (Medium) Pre-Missions hands-on friction elsewhere: instruction drift, slow repo indexing. (AI Leverage, AI Tidbits)
• Bottom line: as of Aug 2026, no independently verified multi-day mission run exists in public — every metric traces to Factory. Third-party "reviews" (Fritz, CAIO Weekly) don't actually run missions.
• Small tooling ecosystem exists: droidgear (Tauri GUI with a MissionsPage), droid-patch (binary patcher), Electron wrappers, DeepSeek-as-worker guides — mostly GUI wrappers and model substitution.

14. Factory's own open questions

From docs, launch post, and the ZenML talk writeup:

1. Is parallelization necessary (vs serial reliability)? Serial execution currently limits throughput.
2. Long-horizon error accumulation despite milestone validation.
3. Cost vs quality tradeoffs; validation overhead not publicly quantified.
4. Orchestrator over-scoping; worker scope trade-offs (narrow focus vs coordination overhead).
5. Single vs multi-layer orchestration for very complex projects.
6. No public failure-rate data whatsoever.

Caveat log

• All duration/token/quality stats are Factory self-reported; zero independent replication.
• Prompt capture is from CLI v0.84.0 (Mar 2026); current CLI is v0.186.0 — internals may have drifted (gist updated Aug 2026, but capture date governs).
• Capture showed Opus-4.6-only vs claimed multi-model routing — unresolved.
• "40 days" claim (36kr) contradicts Factory's own 16-day max — treat as garbled. "Open-source Open Droid" (BigGo summary) — uncorroborated, likely summarization error.
• Customer-specific Mission usage stories (Nvidia CUDA, Morgan Stanley risk models) are aggregator-sourced with unclear provenance.
• One fetch mis-dated the launch as 2025; snowflake IDs confirm Feb 26, 2026. 36kr gives availability as Mar 2, 2026 (likely regional rollout lag or error).
• Not yet read (fetch failures): McKinsey Grinberg interview (~Apr 2026), Reyes "The Build System: Mission Impossible" talk video (Mar 2026), linux.do Chinese community thread.