Tasks
Assignments and dependencies
On this page
An assignment says who should act. A dependency says what must happen first. Use both to give work a clear owner without losing the relationship to other Tasks.
Assign a person, Agent, or Team
You can assign a Task to a Human or Agent, queue it with a Team, or leave it without an implementer. The person making the assignment needs permission, and the selected member or Team must belong to the Workspace.
The implementer choice changes who is expected to take the next step:
| Assign to | Who owns the work | What happens next |
|---|---|---|
| Human | The named person | They pick up and carry out the Task. Assignment does not start an Agent implementation Run on their behalf. |
| Agent | The named Agent | Actionable work enters its execution queue, subject to timing, planning, approvals, dependencies, access, budget, and capacity. |
| Team | The Team's queue until routing is settled | The lead chooses a member, defers the work, blocks it with a reason, or cancels it. Routing can require your approval. An eligible Human can also claim Team work. |
| Unassigned | No implementer yet | Choose a member or Team when you are ready to place responsibility. |
Planner and Reviewer are separate roles. Assigning a Human implementer does not prevent a configured Agent from planning or reviewing that Task.
A Team assignment does not start every member or make the lead the default implementer. Once routing selects a member, the Task becomes a direct assignment and follows that member's behavior above.
See Team lead routing for the lead's recommendation and the Inbox decision where you can adjust, apply, or reject it when approval is required.
When a Project's Workflows consistently route work through one Team, the create form suggests that Team first. You can keep the suggestion or choose another implementer.
Choose the planner and reviewer
Open People to choose the Implementer, Planner, and Reviewer, one tab each. The button names the Implementer and shows a small icon when you chose a Planner or Reviewer yourself. Leave the Default choice selected when you want Task Machine to use the configured defaults. It names who that is, for example Default (Atlas), and updates as you change the Implementer, Project, or Goal.
Explicit Task roles take precedence. Remaining defaults resolve independently through the assigned Agent, Project, Goal, and Workspace. Without a configured planner, the implementer plans the work. Human-review settings keep review with a Human rather than turning it into another Agent turn.
The planner prepares the Task spec. The reviewer assesses plans when review is required and signs off completed work. These roles need not belong to the same person or Agent.
Understand when work starts
Assigning an actionable Task to an Agent puts it in the appropriate execution queue. It still needs permission, the required approvals, cleared dependencies, budget, and available Cloud or Local execution.
Autonomy comes from the first concrete configuration in the Agent, Project, Goal, then Workspace order. An active Workflow step can impose a stricter ceiling. Assignment does not bypass those controls.
Reassigning a Task removes it from the old Agent's queue before it starts. Cancelling or archiving the Task stops the work. Scheduled work becomes eligible when its time is due rather than requiring a second instruction from you.
Put one Task up next
Choose Run next from a Task's action menu or its Next step card when its current next step should start now. It takes the next compatible execution slot, even when the Agent planned the step for later. The request applies once, and it ends when the step runs or a newer step replaces it. You can remove it before then.
Run next does not change Priority or due dates, interrupt running work, or release a Task held by an approval, dependency, budget, or unavailable worker. The request waits for that condition, and the Task shows what it is waiting for. It is unavailable while a run is already active on the Task.
Outside Run next and your comments, Urgent and High work start first, Urgent before High. Project fairness shares the remaining capacity. Scheduled work follows its own capacity and Project-fairness rules. Equally urgent work is further ordered by its delivery target and state.
Connect dependencies
Use Blocked by for work that must happen first and Blocks for work that depends on this Task. One relationship appears from both sides. Task Machine rejects self-dependencies and cycles.
An unfinished blocker normally keeps a Task out of automatic Agent execution. Completion, cancellation, or rejection of the upstream Task proposal can release it. When there are several blockers, each must reach its own release boundary.
Repository work can release a downstream start earlier
An active repository-backed blocker can release automatic downstream work through a linked open or source-confirmed merged pull request for its current repository, when its Project requires pull-request delivery.
Optional pull requests, closed unmerged pull requests, repository-free work, and pending Task proposals do not provide that early release. CI, mergeability, readiness, and review still govern delivery of the upstream work itself.
The dependency remains visible after an early release because the downstream Agent still needs that source context. Task detail shows an amber warning while a blocker holds automatic work and a green check when it no longer does.
Give a specific instruction without removing the dependency
If one turn should start while a dependency still holds, tag the assigned Agent in a comment and explicitly ask it to begin. This instruction applies to that comment-triggered turn. It does not remove the relationship or bypass spec approval, permissions, budgets, repository access, or review.
Use Comments and attachments for thread ownership and handoffs, and Blocked work when the Task is waiting on an outside condition rather than another Task.
Keep proposed assignments inactive until approval
A proposed Task can include one Human or Agent implementer, or a Team, along with optional Planner and Reviewer choices. These assignments do not start execution, planning, or review while the proposal waits.
Review and approve the Task in Inbox. If you can approve a proposal but cannot assign Tasks, you can approve its stored role choices without changing them.
Follow-up Tasks pre-planned in a Work Spec are created from that plan's review instead, and the Task that planned them blocks each one. See Task specs.