Dispatch and execution

Dispatch turns an approved plan into a dependency-aware task graph, gives each specialist focused context, selects the strongest available execution mode, and records every result as a durable handoff.

approved plan -> task graph -> route each lane -> execute -> handoff -> review

Dispatch · current and target

map / active

The receipt contract survives every execution mode

Contract

approved lanetask_run.v1mode × tier × hosthandoff receipt

Current tmux

specialist paneone or more taskstyped receipts

Target

one taskone ephemeral agenttyped receipt

If a capability disappears, routing steps down visibly and records the degradation. It never relabels sequential work as native parallel execution.

Parallelism is an optimization, not the contract. The shipped resolver falls back from tmux teams to the in-process subagent path. A dedicated SerialBackend exists as the universal-floor contract, but no production path constructs it yet; serial-only execution remains a forward-prep target.

From plan lanes to task runs

Each executable lane gets a guild.task_run.v1 record. The tmux launcher also writes one guild.task_assignment.v1 file per specialist pane, but that assignment channel is not authoritative yet: workers do not read it in production, and multiple tasks owned by one specialist collapse onto the first representative task. Together, the shipped run record and receipts answer:

Question	Durable answer
What must this lane produce?	guild.task_run.v1 with scope, acceptance, and artifact path
What context may it use?	A focused context bundle pointer
Which model capability is requested?	Canonical tier key, not a provider-specific model name
What must happen first?	Explicit dependency task IDs
What execution mode was selected?	Recorded agent mode and backend
What happened?	State transitions, attempts, timestamps, and trace events
What did the lane deliver?	Typed handoff receipt with artifacts, issues, and status

The topological graph determines what is eligible to run. The backend determines whether eligible tasks run concurrently or sequentially.

The execution-mode ladder

Guild Stack selects the strongest healthy mode available for the current host and policy:

1. Native agent teams — parallel lanes using the host’s team primitives.
2. Process or pane workers — isolated worker processes with file-backed assignments and receipts.
3. Subagent fallback — in-process delegation when independent workers are unavailable.

The fourth conceptual rung is serial execution, one eligible lane at a time. Its backend class ships, but it is not wired into the production resolver. Today auto bottoms out at the in-process subagent rung and records that downgrade.

Degradation must be visible. A run records the selected mode, unavailable capabilities, and fallback reason. It must not pretend that sequential execution was native parallelism.

Routing uses task evidence

The router evaluates task shape rather than choosing a model by habit. Relevant signals include:

• domain and specialist capability match;
• implementation, review, research, or writing task type;
• reasoning depth and context size;
• risk and required reviewer independence;
• configured cost or time budget;
• host capabilities and allowed model tiers;
• prior lane failure or escalation evidence.

The plan requests a canonical tier. The host profile maps that tier to an available model or records that the tier collapsed or was unavailable.

Focused context, not a shared prompt dump

Before launch, each lane receives a context bundle with three layers:

1. Universal project constraints needed by every specialist.
2. Domain knowledge relevant to the specialist role.
3. Task-specific files, decisions, and acceptance criteria.

This keeps unrelated repository detail out of the lane while preserving traceability to the source files that were selected.

Handoffs are the completion contract

A chat message saying “done” does not complete a task. The specialist writes a typed receipt under:

.guild/runs/<run-id>/handoffs/<specialist>-<task-id>.md

The receipt records status, summary, artifacts, issues, escalation reason, and learning candidates. The lead and review phase consume that same file. See Agent Communications for the envelope and bus schemas.

Shipped task cells and the target contract

The durable contract is one task run and one accepted handoff per attempt. The current tmux realization does not yet enforce one fresh agent process for every task:

Surface	Shipped today	Target
Runtime identity	One pane per specialist; a specialist with multiple plan tasks reuses that pane and receives only the first representative assignment.	One agent instance per task_run_id and attempt, never reused.
Assignment channel	Files are written and exported, but production workers do not read or acknowledge them.	Assignment is authoritative; write and read acknowledgement happen before work.
Dismissal	Completion emits a dismiss signal and reaps panes already dead; it does not terminate a live completed pane.	Receipt acceptance is followed by confirmed process or pane termination.

Treat one-agent-per-task language as the task-cell target until those runtime gaps land. The run, handoff, review, and trace artifacts remain the durable evidence boundary in the meantime.

Failure, liveness, and recovery

Execution distinguishes a slow task from a dead lane and a failed lane from missing evidence:

Signal	Response
Healthy heartbeat, task still running	Continue and report progress
Idle worker with no receipt	Nudge, then escalate or reap after bounded retries
Failed attempt with recoverable cause	Record the attempt and retry within policy
Repeated or terminal failure	Mark the task failed or dead-lettered with evidence
Host capability disappears	Re-route to the next allowed execution mode
Receipt is malformed or absent	Keep the task incomplete; do not infer success from chat

Recovery never erases prior attempts. A later attempt appends evidence so the final result remains auditable.

What to tune — and what to leave alone

Use defaults for ordinary work. Tune execution only when the task has a concrete need:

• Add dependencies when two lanes would otherwise edit the same contract in the wrong order.
• Constrain parallelism when shared resources or repository overlap create risk.
• Raise a tier when evidence shows the task needs deeper reasoning.
• Require cross-host review when independence materially improves confidence.
• Force sequential mode when the host substrate is unstable but the task can still proceed safely.

See also

• Specialist Roster for role and capability selection.
• Context Assembly for the three-layer bundle.
• Cost-Aware Model Tiering for canonical tiers and budgets.
• Agent Communications for assignments, receipts, and bus events.
• Adversarial Review for the gate that follows implementation.