Room 03 · Dispatch
The dispatcher turns grounded work into a governed run.
It checks readiness, selects an execution configuration informed by complexity, capability, capacity, and cost, then hands the work to one isolated runner.
What enters
The dispatcher receives a grounded Yesod note: the original intent, acceptance criteria, a build plan expressed as a tree of Beads, a complexity estimate, and any dependencies on other notes.
Planning makes work understandable. It does not, by itself, authorize execution.
Readiness before routing
Before a runner can claim the work, the dispatcher checks that the note is in an executable lifecycle state, its plan is current, its governing Bead is ready, note dependencies are complete, the repository is ready, an eligible runner has capacity, retry limits allow another attempt, and no equivalent live claim already exists.
The claim is atomic. Two runners should not discover the same work and both believe they own it.
Selecting the execution configuration
The complexity estimate informs model choice; it does not make the choice. The dispatcher considers:
- the capability required by the plan;
- available models, coding harnesses, runners, and VM capacity;
- the run’s time, token, and cost budget;
- model or host pins and preferences; and
- the routing reason that will be recorded with the run.
A pin is a constraint, not a promise of an undocumented fallback. If no allowed configuration is ready, the work should wait or become explicitly blocked instead of silently changing policy. A “coder plan” is not part of the public routing contract until its role and persistence are defined.
The result of routing is the grounded note and its Bead tree plus a selected execution configuration: model, harness, runner or VM, budget, and recorded routing reason.
One runner, one bounded job
The selected runner creates a durable run, checks out an isolated worktree from a known base, and starts the chosen coding harness and model with the build plan. Time, token, retry, heartbeat, and termination limits belong to the surrounding runner—not to the agent’s discretion.
For code, the worker commits incrementally, runs focused tests, pushes a named candidate branch, and verifies that the remote branch is retrievable. It proposes work; it does not merge, deploy, or grant itself production authority.
What comes out
For a successful coding run, the usual output is an evidenced merge candidate attached to the original note and Bead tree. Other factories may produce a document, analysis, data artifact, operational proposal, or another bounded deliverable.
Failure is also an outcome: the run records what ended, why it ended, and whether retry, replanning, or operator attention is appropriate.