Foundation
One job establishes the canonical contract, storage boundary, or shared interface with focused tests.
Swarming
Task Programs
A Task Program is a pre-planned, end-to-end prompt for work that needs multiple dependent stages. It tells Swarm what can run now, what must wait, when successful commits should be integrated, and how each stage hands off to the next.
Swarm creates Task Programs when appropriate, but you can override that choice by asking, Make me a Task Program
, in Plan mode or the default mode.
Sample Task Program
One approved program carries the work from brief to final handoff.
A Task Program is essentially a pre-planned, end-to-end prompt. Before execution starts, it defines the jobs, their order, the dependencies between them, what each worker must deliver, and the checks each result must pass.
Swarm runs that reviewed program stage by stage. Successful Coder jobs work in isolated worktrees, make scoped commits, and return clean handoffs. Swarm integrates accepted commits before dependent work begins, then reports the final result, commit evidence, and validation in the checkpoint handoff.
Task Programsample-image-feature · 0/4 jobs · 0/3 phases
0%
DeclaredNext: run foundation
Approved brief
Establish the shared contract, build both consumers against it, then audit the integrated feature.
Phase 01 foundation
Ready0/1Dependencies: ready · no unfinished child work
01ReadyImage Core Contract@Coder · isolated worktreeFocused tests + scoped commit↓ Integration barrier Accept the clean foundation commit into the parent.
Phase 02 consumers
Waiting0/2Dependencies: after foundation · integrated core contract required
01WaitImage API Consumer@Coder · isolated worktreeAPI tests + scoped commit02WaitImage Runtime Consumer@Coder · isolated worktreeRuntime tests + scoped commit↓ Integration barrier Accept both independent commits before audit begins.
Phase 03 audit
Waiting0/1Dependencies: after consumers · integrated feature required
01WaitImage Integration Audit@Coder · fresh contextCross-system review + validation
- You approve the whole route first. The program is reviewed as one end-to-end execution contract instead of being improvised between stages.
- Dependencies control the order. Ready jobs can run together, while downstream jobs wait for accepted prerequisite work.
- Commits are part of the workflow. Successful Coder jobs return scoped commits; Swarm integrates them at the declared barriers before continuing.
- Handoffs preserve accountability. Each job reports its deliverable and evidence, and the checkpoint receives one final summary of the integrated result.
When to use one
Use a program when later work needs integrated earlier work.
A Task Program earns its structure when the request crosses material subsystem boundaries, contains several substantial responsibility clusters, or needs a final audit that should begin only after implementation is integrated.
Do not use one for a single cohesive edit, one independent delegated wave, or several alternatives that do not depend on each other. Those are better handled directly, through regular delegation, or through an Iteration Swarm.
Natural-language request
“Build the image feature as a Task Program: establish the core contract first, then implement independent API and runtime consumers, then run a fresh-context integration audit.”
Program anatomy
Stages control readiness. Jobs own deliverables.
stagesOrdered execution boundaries such as foundation, consumers, and audit. A stage opens only after the stages it depends on reach their integration barrier.jobsBounded assignments with one agent type, title, complete brief, deliverable, acceptance criteria, and dependency evidence.depends_onThe explicit edge between a prerequisite and the job or stage that consumes its accepted, integrated result.owned_scopeThe files or directories a Coder or workspace Designer may own. Managed Designer jobs omit it and return managed artifacts instead.integration barrierThe point where successful prerequisite work is accepted into the parent state before downstream work begins.Approved programs become canonical
When a Task Program is attached to an approved checkpoint, that reviewed graph is the execution contract. Swarm loads it directly rather than rebuilding the program from conversational notes.
Three-stage pattern
Foundation → consumers → audit.
Consumers
Independent jobs implement API, runtime, UI, or other consumers against the now-integrated foundation.
Audit
A fresh-context job reviews the integrated system, fixes cross-boundary gaps, and records focused validation.
Program: image-feature
foundation
└─ core-contract
consumers (after core-contract)
├─ api-consumer
└─ runtime-consumer
audit (after both consumers)
└─ integration-audit- Keep every job independently reviewable and give it local acceptance criteria.
- Run dependency-ready jobs in the same stage concurrently only when their writable scopes do not overlap.
- Let the final audit inspect the integrated state; do not ask a foundation worker to certify all downstream behavior.
- Expect Coder jobs to use isolated worktrees and return committed, clean handoffs.
Recovery
Preserve completed work and replace only the unfinished graph.
Task Programs do not have a resume, redeploy, or continue operation. If a program blocks, Swarm inspects the durable status, verifies the blocker, preserves completed and integrated jobs, and recovers any safely usable child work.
After the blocker is fixed, Swarm creates a new Task Program containing only unfinished jobs. It does not replay completed work or pretend that a failed first attempt succeeded.
Good recovery boundary
Fix an integration conflict or missing permission first, verify the parent state, then launch a new program for the remaining consumers and audit. Repeating the same blocked program without new evidence is not recovery.