Task types
Most work is an ordinary task: a title, a spec, an assignee, and a status that moves from open to done. Eight specialized types exist for work whose shape is known in advance, and each of them replaces the ordinary statuses with a lifecycle of its own.
A specialized type is not decoration. The type is what tells the platform which steps come next, which of them need you, and which event to publish when it finishes.
The eight types
Section titled “The eight types”| Type | What it is | Created by |
|---|---|---|
| Content | A piece of content taken from idea to published | A huddle that agrees to a piece of content, or + New on the Tasks page |
| Verification | A check of somebody else’s work against a rubric | An initiative reaching a station that has acceptance criteria, or a content task entering verification |
| Approval | A decision only a person can make | An agent that hits an action its autonomy level will not let it take alone |
| Feedback | Collecting what happened after something shipped | A content task reaching its measuring stage |
| Scheduled trigger | Work that is held until a time, then fires once | Scheduling a content asset onto the calendar, or a content task reaching its scheduling stage |
| Setup | A value or a decision an agent needs before it can go on | An agent missing a credential or a setting, or a capped run offering its branch |
| Capstone | The huddle’s own final check, run against the work every task merged into | A huddle whose drafts merge into a project with a repository |
| Assist | A blocker only a person can clear, raised from inside a run | An agent that cannot go on without you |
Content
Section titled “Content”A content task walks a pipeline rather than a status: it is captured, then ideated, drafted, verified, put in front of you for review, scheduled, and finally measured. Review sits in the middle by design, so nothing reaches a channel without a person seeing it first, and sending a draft back to drafting is a normal move rather than a failure.
Verification
Section titled “Verification”A verification task scores work against a rubric: a named set of criteria with weights and a passing score. It starts pending, moves to scoring while an agent works through the rubric, and resolves as passed, failed, or needs revision. Verification is how a claim like “this is ready” becomes a result you can read.
Approval
Section titled “Approval”An approval task is the platform asking you a question it cannot answer. It carries the action being proposed, and it resolves as approved, rejected, or expired. Approvals appear in your approvals queue, and the run or agent that raised one waits for the answer rather than proceeding on an assumption.
Feedback
Section titled “Feedback”A feedback task waits for a measurement window to pass, collects what actually happened, and closes by recording what was learned. It is the last station of the loop that starts with shipping something: results come back as work, not as a dashboard nobody opens.
Scheduled trigger
Section titled “Scheduled trigger”A scheduled trigger holds a time and an action. It waits, fires at that time, and does the thing it was created for: publishing an event other work reacts to, or moving another task along. Recurring work is expressed this way rather than as a task somebody remembers to re-create.
A setup task asks for one thing and says where the answer lands: anything secret-shaped is stored as a secret, never as text on the task. The run waits until you answer.
Capstone
Section titled “Capstone”A capstone belongs to no branch: it waits until every task in the huddle that touches the repository has merged, then runs against that collected work. Accepting it opens the pull request.
Assist
Section titled “Assist”An assist is the outlet for an agent blocked on something only a person can do, such as an access it cannot grant itself. The work is pushed before the run parks.
code is not in this table: it changes a run’s budget rather than a task’s lifecycle.
What a type changes
Section titled “What a type changes”Choosing a type changes four things:
- The lifecycle. Each type has its own states and its own legal transitions, and a transition the type does not allow is refused.
- The payload. Each type carries structured data of its own, such as the rubric a verification scores against or the action an approval proposes.
- What happens on completion. Finishing a typed task publishes an event, which is what lets a verification result unblock a content task or an approval release a paused run.
- Where it appears. Typed tasks are filterable, so approvals, verifications, and scheduled work each have a view of their own.
Next steps
Section titled “Next steps”- Tasks: the spec, keys, and grounding every task shares.
- The autonomy ladder: what decides whether an action becomes an approval task.
- Using CommandChain: the guides for working with each type.