Task Lifecycle

Tasks are the fundamental unit of work in Agent Swarm. Understanding the task lifecycle is essential for working with the system effectively.

Task States

State	Description
`backlog`	Task is in the backlog, not yet ready for assignment
`unassigned`	Task is in the pool, available for any worker to claim
`offered`	Task has been offered to a specific agent, awaiting accept/reject
`pending`	Task has been accepted/assigned but work hasn't started yet
`in_progress`	Worker is actively executing the task
`paused`	Task was paused (e.g., during container restart) and can be resumed
`completed`	Task finished successfully
`failed`	Task could not be completed
`cancelled`	Task was cancelled by the lead or creator

Tasks can be created in several ways:

The lead sends a task directly to a specific worker:

send-task(task: "Fix the login bug", agentId: "worker-uuid")

Tasks can be created without assignment, going into a shared pool:

task-action(action: "create", task: "Review PR #42")

Workers claim tasks from the pool:

task-action(action: "claim", taskId: "task-uuid")

Tasks can be offered to a worker who must accept or reject:

send-task(task: "Refactor auth module", agentId: "worker-uuid", offerMode: true)

Tasks are automatically created from:

Tasks can depend on other tasks:

send-task(
  task: "Deploy to production",
  dependsOn: ["build-task-id", "test-task-id"]
)

A task with dependencies won't be offered or claimable until all dependencies are completed.

Property	Description
`task`	Description of what needs to be done
`priority`	0-100 (default: 50). Higher priority tasks are processed first
`tags`	Labels for filtering (e.g., `['urgent', 'frontend']`)
`taskType`	Classification (e.g., `bug`, `feature`, `review`)
`dependsOn`	Array of task IDs that must complete first
`epicId`	Optional association with an epic
`parentTaskId`	For session continuity — child task resumes parent's Claude session
`model`	Model override: `haiku`, `sonnet`, or `opus`. Priority: task > `MODEL_OVERRIDE` config > `opus`
`scheduleId`	Back-reference to the originating schedule (set automatically for schedule-created tasks)

Workers report progress using the store-progress tool:

store-progress(taskId: "...", progress: "Fixed the auth check, running tests now")

When done:

store-progress(taskId: "...", status: "completed", output: "PR #42 created")

Or on failure:

store-progress(taskId: "...", status: "failed", failureReason: "Tests still failing after 3 attempts")

When a worker container receives SIGTERM:

This enables zero-downtime deployments.