馃悵

Swarm

The parallel execution engine

Swarm takes a plan that already carries branch steps and runs those branches in parallel. It dispatches each branch into its own session, tracks status, retries failures, surfaces sibling state, and resumes interrupted work across sessions. Mechanism, not policy. Governing decides what gets done. Swarm does the doing in parallel.

What swarm is now

A compound task is one that naturally splits into independent sub investigations that need to reconverge. Build a server plus a frontend plus tests. Write a research paper with literature review, methodology, results, discussion. Draft a book, one branch per chapter. Design a data pipeline with ingestion, transform, validate, export.

Swarm is the engine that runs those branches in parallel without losing track of them. It does not draft the decomposition. It does not ratify the shared vocabulary. It does not decide who gets what work. Those are governing's job. Swarm reads governing's emissions and runs the branches the plan named, in the modes the plan declared, under the contracts in force.

Division of labor

In v0.2, swarm shed the work it shouldn't have been doing. Plan emission, contract ratification, role coordination moved to governing. What remained is the part swarm was always best at. Parallel dispatch and bookkeeping.

馃憫 Governing owns

Plan emission via the Planner. Contract ratification via the Contractor. Role coordination via the Ruler. Call stack discipline via the Foreman. Workspace specialized production via the Worker. The deciding and the judging.

馃悵 Swarm owns

Parallel branch dispatch. Branch status tracking. Tree authoritative reconciliation. Sibling visibility. Resume detection across sessions. The mechanism that makes governing's plans run in parallel without anyone losing track of what's happening.

馃敡 Workspaces own

Domain specific tools and validators that fire on swarm's lifecycle hooks. code workspace runs syntax checks, contract conformance, smoke tests. book workspace runs voice continuity, character consistency. Whatever the domain produces, the workspace validates.

How it works

Five phases. Each is mechanical. Plan in, branches running, results out.

1

Reconcile

Before any dispatch, swarm runs reconcileProject to walk the actual tree children and merge them with the cached subPlan. New children become pending entries. Deleted children drop. Renamed or rewritten specs refresh from node metadata. The tree is ground truth. The cache adopts reality.

2

Dispatch

For each branch step in the plan, swarm promotes the child node to a sub Ruler (via governing's promoteToRuler) and spawns a recursive turn at that scope. Contracts in force at the parent scope are visible to the sub Ruler. The sub Ruler runs its own full lifecycle. Plan, contract, dispatch.

3

Track

Swarm watches the branch step status. Pending, running, done, failed, blocked. Status writes are atomic and dual sourced (plan node and swarm metadata) so the picture stays consistent even across concurrent dispatches.

4

Reconverge

When all branches at a step settle, swarm fires swarm:afterAllBranchesComplete. The Foreman wakes to judge terminal status. Workspace validators run. Failures get retried (or escalated per the Foreman's decision). Success rolls up.

5

Resume

When a session is killed mid build, detectResumableSwarm walks the tree to find branches still pending or running. The Foreman reads the resumable set on next user contact and decides whether to redispatch. Pause markers and frame anchors written by the Foreman survive session refresh.

Tree authoritative

The most important architectural property of swarm. The tree node graph is ground truth. Cached state (subPlan, queues, in memory progress) is a working copy that reconciles against the tree on every dispatch and resume.

This matters because trees outlive sessions. A user can navigate away, edit nodes by hand, import work from offline tools, run mycelium federation that mutates a peer's tree. Two weeks later, swarm picks up where it left off. Not by trusting its cache. By rereading the tree.

Without this property, every recovery would mean rebuilding state from scratch or trusting stale assumptions. With it, the tree is the database, and swarm is just the runtime that animates the parallel dispatch.

Siblings are legible

Branches don't run blind. readSiblingBranches returns a read only snapshot of every sibling branch's state and descendant notes. Domain neutral. Domain extensions render it however they want.

code workspace

Renders sibling state as a partial file tree. The frontend branch can see what files the backend branch has produced before writing its fetch calls.

book workspace

Renders sibling state as chapter summaries. Chapter seven can see which characters are alive after chapter six landed.

research workspace

Renders sibling state as section claims. The discussion branch sees what the methodology branch committed before drawing conclusions.

The visibility is structural, not coordinated by hand. Branches that need each other's outputs read them through the same primitive regardless of domain.

Hook lifecycle

Swarm fires hooks at every stage of dispatch. Workspace extensions subscribe to add domain specific behavior without importing swarm directly.

swarm:afterProjectInit

The project is initialized and ready for dispatch. Workspaces can stamp project level metadata or seed structural files.

swarm:beforeBranchRun

A branch is about to dispatch. Workspaces can inject per branch context, claim resources, or prepare validator state.

swarm:afterBranchComplete

A branch declared done. Workspaces run per branch validators (syntax, smoke, voice, citation) and stamp status.

swarm:branchRetryNeeded

A branch failed validation and the Foreman judged it recoverable. The branch will redispatch with the failure reason in context.

swarm:afterAllBranchesComplete

All branches at a step settled. The Foreman wakes for terminal status judgment. Workspaces can run cross branch validators (integration, seam, contract conformance).

swarm:runScouts

The seam verification phase. Scouts run cross branch checks, route discovered issues back into branch inboxes for redispatch. Loops until clean or capped.

What moved to governing

Earlier versions of swarm carried responsibilities that didn't really fit. v0.2 moved them to governing where they belong. If you remember the old shape, here's the map.

  • The architect (decomposition role) is now governing's Planner.
  • Contract emission is now governing's Contractor, with Ruler ratification.
  • Plan lifecycle events (proposed, updated, archived) moved to governing:plan* hooks.
  • The judgment surface for failures and resume decisions is now governing's Foreman.
  • Branch dispatch into a sub Ruler turn replaces the old direct mode dispatch. Each branch is a recursive Ruler scope, not a Worker pretending to coordinate.

What stayed in swarm. Everything mechanical. Reconciliation, dispatch, status tracking, sibling visibility, resume detection. The plumbing that makes parallel branches run without governing having to babysit them.

Why parallel execution is a primitive

Humans already do this. Teams split a project into parts, each person works in their own head, and they reconverge through shared language and specs. The word "branch" isn't new. The word "merge" isn't new. What's new is making parallel execution native to an AI operating system instead of a process a human ties together.

Small models don't have room to hold a backend, a frontend, a persistence layer, and a test suite in the same context window. They can hold one of those at a time. Swarm gives each one its own context, its own position, its own conversation. Coherence is handled by the contracts (which governing ratifies), not by cramming everything into one turn.

The result is compound work that would take a 200B model hours in one shot, done by many 27B models in parallel with governing keeping them aligned and swarm keeping them moving.

GoverningSee It In CodeBack to the Seed