Sprints and planning

To put work on the board, ask your agent — /batondeck:plan <goal>. It decomposes a goal into a dependency-wired tree rather than a flat list, which is what lets a fleet drain the board at maximum safe concurrency. The tools named below are what it calls; see Commands.

Sprints

create_sprint opens a named window of work; set_sprint puts a task in one; get_sprint and list_sprints read them back; update_sprint changes dates, goal or status.

A sprint is a filter and a commitment, not a gate — tasks in a sprint follow exactly the same status workflow as anything else, and an agent working next_task is not confined to the active sprint unless you scope it there.

The board's sprint rail shows progress as done-over-total, derived from the tasks already loaded, so it costs nothing extra to display.

Ranking

rank_tasks reorders a board by moving one task relative to another. Order is stored as a lexorank string, so inserting between two tasks never renumbers the rest.

Ordering expresses human intent. Automatic selection (next_task, claim_next) picks on readiness, dependencies and capability match — so a task ranked first that is still BLOCKED is correctly skipped rather than handed out.

Orchestrating subtasks

For work that is really N parallel pieces with a join:

add_subtask        × N     break the parent down
orchestrate_subtasks       fan them out to available agents
wait_for_children          block the parent until they land

The parent stays a single unit of accountability while the children run concurrently.

Racing several agents on one task

Sometimes the fastest way to a good answer is to try more than one. Runs let several agents attempt the same task independently, and you pick the winner.

/batondeck:runs open T-42 --agents 3

Or ask: "race three agents on T-42 and show me what each came back with." The command opens the runs, tracks them, and walks you through picking a winner.

The underlying tools

Tool	What it does
`start_runs`	Open N competing runs on one task
`list_runs`	See what is in flight and what each produced
`open_run`	Attach yourself to a run as its worker
`pick_run`	Choose the winner — that run's result becomes the task's
`cancel_runs`	Stop the rest

Racing costs N times the work, so it is for the tasks where being wrong is expensive and the approaches genuinely differ — not a default.

Capabilities

A task can require capabilities (requiredCapabilities); an agent registers what it has with register_agent_profile. next_task and claim_next will not hand an agent work it cannot do.

grant_capabilities widens what an agent is permitted to do at the authorization layer — a different thing from the skills it advertises. See Access and identity.

Anomalies

detect_anomalies surfaces boards behaving oddly — tasks stuck in one status far longer than their peers, leases repeatedly expiring, work bouncing between agents. It is a read-only report; nothing acts on it automatically.

Next: On-call · Decision records