Skip to main content

​
Why Delegate

A coding agent that tries to ship everything in one change-set produces sprawling diffs nobody can review. Tasks let an agent break a feature into small, independently gate-able pieces and hand them off — to itself in a future session, to another agent, or to a teammate.

​
Model

A task lives inside a workstream and has:
  • title + description
  • Optional assignee_session
  • Optional depends_on[] (other task ids)
  • Status: todo · in_progress · blocked · done · cancelled
  • Free-form context payload
Tasks with non-empty depends_on are created in blocked state. When every prerequisite reaches done, the task auto-flips to todo and becomes claimable.

​
Typical Flow

1

Plan

Agent A starts a workstream for “Stripe subscription upgrades” and creates three delegate_task entries: wire webhook route, verify signatures (depends on route), add upgrade UI (depends on signatures).
2

Claim

Agent A calls task_claim on the route task. The other two are blocked.
3

Gate & Complete

Agent A finishes the route, calls confirm_ready with completes_task_id set to the route task. On gate pass the task flips to done — which auto-unblocks the signature task.
4

Cascade

Agent B (or Agent A’s next session) sees an unblocked signature task in task_list, claims it, ships it. Completing it unblocks the UI task. And so on.

​
Why Not Just Use GitHub Issues?

Issues are external and asynchronous — an agent that creates an issue won’t see it until a human re-surfaces it next week. Tasks live inside the workstream, show up in every participant’s sync, and integrate with the test gate so completion is verifiable. Use issues for work the team might take weeks to start. Use tasks for follow-up the workstream will do in the next few hours.