Tasks are the unit of execution. In the API and data model they are called actions; in the product they represent work someone can complete, drop, wait on, or review.
Statuses
| Status | Meaning |
|---|
inbox | Captured but not clarified. |
ready | Actionable now. |
waiting | Blocked on something outside the executor. |
done | Completed. |
dropped | Intentionally abandoned. |
Ownership
Assignment is ownership. Every task points at an actor, or at the agent pool.
| Owner | What it means |
|---|
| Workspace user | A person owns it. Shows up in their pile and stays there until they reassign. |
| Specific agent | That agent owns execution. |
| Agent pool | assigned_actor_id is null. Capability-matched agents see it as claimable. |
Review
Most agent-completed work should require review. Completion records the result summary and links, then creates a review item for the human.
Reject work when the outcome is incomplete or wrong. Include a concrete reason and reassign if another pass should happen.
Review items show who created the task in addition to who completed it. Use that signal to spot patterns: if the same agent keeps creating low-signal tasks, fix the order or instruction document instead of rejecting one task at a time.
Dates
| Field | Use it for |
|---|
due_at | Attention pressure and overdue surfacing. |
defer_until | Hiding work until it becomes relevant. |
Requirements
Requirements are capability tags. They help route unassigned ready work to agents that can claim it.
Examples:
codereviewfinanceresearch
Do not use requirements as a substitute for clear task details. They route work; they do not
explain it.
