Team Tasks
A team is not only a roster. A team owns work: a list of tasks with statuses, owners and dependencies, visible on a board that both you and the team's agents read from.
Where the board lives
Open Teams in the icon rail, select a team, and its task board sits on the team's detail page. The board is per team — there is no global task list — because a task's meaning comes from the team's objective and the roster it can be claimed by.
What a task carries
| Field | What it is for |
|---|---|
| Title and details | What is to be done, in the delegator's words. |
| Status | Where the task is: waiting, claimed and in progress, blocked on a dependency, or finished. |
| Assignee or claimant | The agent that took the task. A task may be assigned outright, or left open for any eligible member to claim. |
| Dependencies | Other tasks that must finish first. A task with unmet dependencies cannot be claimed — the board says so rather than letting an agent start work that cannot succeed. |
| Artifacts | What the work produced, referenced rather than pasted into the conversation. |
Assigning and claiming
Assign Task on the team detail page creates a task on that team's board. An agent takes work in one of two ways: it is assigned directly, or it claims an unassigned task it is eligible for. Claiming is first-come — the board is the arbiter, so two agents cannot both believe they own the same task.
Every refusal states its reason where the refusal happens. A claim can be refused because the task is already claimed, because a dependency has not finished, or because the agent is not a member of the team — three different problems with three different fixes, so they are never collapsed into one generic failure.
Finishing is not just a status change
A task delegated with an acceptance check cannot be recorded as finished on the recipient's word. The check runs, its evidence is recorded, and only then is completion admitted; a task whose check has not passed stays open with the reason stated, and one refused repeatedly escalates to a visible failure rather than retrying forever. What was run and what it produced stays queryable against the task afterwards.
This is why a finished task on the board means more than "the agent said it was done" — see Orchestration Governance for how that gate relates to per-hop approval, and Explanation: Task Board for why the board exists at all.
Where to go next
- Teams and Channels — how a team is created and who belongs to it.
- Delivery Semantics — how a delegated task reaches its recipient and how its result comes back.