Execution loop

Once a spec is planned, the Queen drives the task graph to completion. The execution loop is where the plan becomes code: the Queen dispatches work to your local Workers, collects their results, and gates every completed task on review before it lands.

Ordering by dependencies

The task graph is dependency-ordered, so the Queen always knows which tasks are ready — their prerequisites are done — and which must wait. She walks the graph in that order, never starting a task before the work it depends on has finished and passed review.

Parallelizing across the Swarm

Independent tasks have no edge between them, so the Queen runs them at the same time, fanning them out to different Workers. The set of Workers active at once is your Swarm. Parallelism is bounded by your plan tier and by how many tasks are actually ready, so the Swarm grows and shrinks as the graph unfolds.

            ┌── Worker A ──▶ task 2 ─┐
plan ──┬───▶│                        ├──▶ task 5 (waits for 2 + 3)
       │    └── Worker B ──▶ task 3 ─┘
       └───▶ Worker C ──▶ task 4 (independent)

Gating on Drone review

A task is not done when a Worker stops typing. Each completed task is handed to the Drones — the server-side auditors — for review. Only work that passes its review advances the plan; work that fails is sent back into the failure handling path instead of landing. See the eight Drones for what they check.

Hierarchical decomposition

If a task turns out to be larger than the plan assumed, the Queen can decompose it further into a sub-graph and orchestrate that the same way. Orchestration is recursive: the same dispatch, collect, review, advance loop applies at every level.

When a task fails

A failed Worker run or a failed Drone review does not stall the whole Swarm. The Queen retries, reassigns, or replans the affected part of the graph. That logic lives in Replanning + retries.