## Summary Redesign fork from a fire-and-forget spawn primitive into a **worker-lifecycle** layer for the orchestrate → delegate → review → iterate → integrate workflow, while holding one line: **fork coordinates, never decides.** All mechanics (isolation, verification, messaging, bookkeeping) become deterministic code; all judgment (decomposition, review verdicts, merging) stays with the orchestrating model. ## Motivation / research basis A three-pronged research survey (practitioner tools, academic/vendor literature, deterministic-loop systems) found: - **Same-session iteration is the convergent pattern** (Devin, Cursor, vibe-kanban, Claude Code `SendMessage`); cold-respawn-per-round is the minority position (Amp). Fork is currently on the wrong side of this. - **Git-worktree-per-agent is the dominant local isolation pattern** (Conductor, Superset, vibe-kanban, Claude Code, Gas Town). Work commits to the chunk branch early; the merge to main is the only approval event. - **Deterministic verification is the only reliable completion gate** (Reflexion, CRITIC, Huang et al., Kamoi et al.); LLM-only review is a noisy signal (position/verbosity/style bias, overcorrection, test-retest instability in the code-judge literature). So judgment stays with the big-model orchestrator, backed by mechanical checks. - **Large-scale successes attribute wins to directed decomposition + engineered verifiers + serialized merging**, not autonomous loops (Carlini's C compiler, Chacon's Grit). Maximal-determinism systems (Gas Town) run ~10× token cost and need guardrails we don't: a single orchestrator *is* the serialized merge point, and its plan is the ledger that matters. ## Non-goals - No plan parsing, scheduling, auto-merge, or approval logic in fork - No reviewer-subagent pipeline (orchestrator review + checks gate instead) - No merge queue / dependency-graph work tracker (Gas Town Refinery, Beads) at this scale - Children never get parent tools (flat hierarchy; recursion guard holds) ## Work items - [ ] #2 Verdict loop: persistent children with `message_agent` / `close_agent` - [ ] #3 Checks gate: `complete_task` must prove green before reporting - [ ] #4 Worktree isolation for `spawn` (`isolate`) - [ ] #5 Ledger: `list_agents` + richer result payloads - [ ] #6 Docs + orchestration playbook in tool descriptions Dependency order: 1 → 2 → 3 → 4 → 5. Each issue is independently shippable and sized as one self-contained chunk of work. ## Key sources - Anthropic, "Building effective agents": https://www.anthropic.com/research/building-effective-agents - Anthropic, "How we built our multi-agent research system": https://www.anthropic.com/engineering/multi-agent-research-system - Cognition, "Don't Build Multi-Agents": https://cognition.com/blog/dont-build-multi-agents - Carlini, "Building a C compiler with a team of parallel Claudes": https://www.anthropic.com/engineering/building-c-compiler - Chacon, "Grit: rewriting Git in Rust with agents": https://blog.gitbutler.com/true-grit - HumanLayer, 12-factor agents: https://github.com/humanlayer/12-factor-agents - Claude Code docs: subagents https://code.claude.com/docs/en/sub-agents · worktrees https://code.claude.com/docs/en/worktrees - Gas Town: https://github.com/gastownhall/gastown · Beads: https://github.com/gastownhall/beads - Huang et al., "LLMs Cannot Self-Correct Reasoning Yet": https://arxiv.org/abs/2310.01798 - CodeJudgeBench: https://arxiv.org/abs/2507.10535 · "Are LLMs Reliable Code Reviewers?": https://arxiv.org/abs/2603.00539