Assignments and dependencies

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

The create form also lets you choose a Planner and Reviewer. Leave Default planner and Default reviewer selected when you want Task Machine to use the configured defaults.

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 an eligible non-scheduled Task's action menu when it should take the next compatible execution slot. It remains Up next until it finishes or you remove that selection.

This is temporary queue steering. It does not change Priority or due dates, interrupt running work, or release a Task held by an approval, dependency, budget, or unavailable worker. Other eligible work can still use spare capacity.

Outside Run next, retries and urgent work take precedence before Project fairness shares the remaining capacity. Scheduled work follows its own capacity and Project-fairness rules. Equally urgent work is further ordered by its state and due time.

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.