Task types
Most work is an ordinary task: a title, a spec, an assignee, and a status that moves from open to done. Five 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 five types
Section titled “The five types”| Type | What it is | Usually created by |
|---|---|---|
| Content | A piece of content taken from idea to published | The marketing side of a project, or a meeting that asks for content |
| Verification | A check of somebody else’s work against a rubric | A content task entering verification, or a release gate you define |
| 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 shipped campaign or asset whose results are due |
| Scheduled trigger | Work that fires on a schedule | Anything recurring, such as a weekly data refresh |
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.
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.