You need an agent and an environment. No roster is required: every agent can run as a team of its own copies. Starting sessions needs the Developer or Admin role; the User role can read the board. See Organizations and roles. Teammates follow the same delegation, inheritance, and limit rules as any copy of the root; see Multi-agent.
When to use a team
Use a team when the work has two or more independent pieces that each take real effort, or when the result should be checked by someone other than its author. For one precise hand-off, use delegation instead. Every teammate is a full agent that runs its own model calls, so a team of four costs roughly four times as much per minute as one agent. It pays off when the pieces are substantial and would otherwise run one after another.Good and poor fits
Good and poor fits
Good fits:
- Competing approaches. Try three ways to speed up a query, each with its own benchmark, then pick the best one.
- Separate components. Build an API client, a CLI, and their docs, each with its own tests.
- Separate questions. Research three vendors, each from its own sources.
- Independent review. Have a second teammate check each result before the decision.
- Steps that must happen in order, where each step needs the last one’s output.
- Pieces that take a few minutes each. The coordination costs more than it saves.
- One precise hand-off. Use delegation instead.
Choose a team mode
The team mode decides whether a session forms a team.
Set the agent’s default under Multiagent on the agent’s Configuration tab, or with
multiagent.team.mode. Override it for one session with team.mode when you start the session:
- Console
- cURL
- In the sidebar, click Sessions, then click Launch session.
- Choose the Agent and Environment.
- Under Task, write the brief in Opening message.
- Under Team, set Work as a team to Always.
- Click Launch session.
202 Accepted with the new session id. Next, watch the board.
Write a good team brief
The brief is your opening message. The leader turns it into tasks, and each teammate sees only its own task body, so the brief has to make the split obvious.- Name the independent pieces. “Compare three approaches: an in-process LRU, Redis, and CDN edge caching.”
- Say where each piece writes. “Put each prototype in
/workspace/proto/<approach>/and its findings in/workspace/research/<approach>.md.” Separate paths keep teammates from overwriting each other. - Give the shared rules once. The test command, the data set, and the format every piece must follow.
- Ask for review when it matters. “Have a different teammate check each result’s numbers.”
- Say how results will be judged and what the final deliverable is. “Pick one approach by p95 latency under the load in
/workspace/bench/run.sh. Save the recommendation ascaching-recommendation.mdwith the numbers for all three.”
Read the board
The board shows every task with its status, owner, notes, and result summary, plus notices, recommendations, and the decision. It’s the authoritative state; refresh from it rather than rebuilding the board from events.- Console
- cURL
- In the sidebar, click Sessions, then open the root session.
- Open the Work tab. The Board lists tasks by status with their owners.
- Click a task to see its body, result summary, output paths, and notes.
- In the transcript, choose the Team filter to see board changes in order.
tasks[].status and owner_session_id for who holds what, tasks[].outcome for finished work, and the decision post for the leader’s call.
Example board
Example board
A board midway through a round looks like this:
What each board field tells you
What each board field tells you
What success means
A team session is finished when the leader has integrated the results and ended its work, the same as any session. Along the way, a round is over when no task isopen or claimed, and an exploratory round ends with a decision post. Deliverables that teammates write count as the root session’s deliverables. See Deliverables and artifacts.
How a team works
The leader posts tasks, teammates claim and finish them, and the leader records one decision. As tasks become claimable, copies of the leader join to take them, up to the team size: the roster’smax_concurrent_threads, which defaults to 8 and can be at most 25.
Teammates are copies of the leader, so they have the leader’s model, prompt, skills, MCP servers, and exactly the same vault and credential grants. See What a child inherits.
Tasks, statuses, and team rules
Tasks, statuses, and team rules
- Tasks. Each task has a label such as
T1, a kind, a self-contained body, and the output paths it will write. Kinds aretask(work with a named output),explore(one approach to an open question), andreview(check another task’s output and leave findings in a note). A task can wait on others withblocked_on. - Statuses.
open(posted and not held; claimable once every task in itsblocked_onis done),claimed(in progress),blocked(the owner can’t proceed and says why in a note),done(finished, with a result summary), anddropped(withdrawn). - One owner per task. A claim belongs to one teammate. A teammate that joined from the board can change the shared sandbox only while it holds a claimed task. A teammate can’t claim the review of a task it did.
- Shared state. Notices are facts every member must know, such as a moved path; the latest 10 stay in front of every member. Teammates can message each other directly, up to 20 messages per assignment, and put what they agree on the board.
- One decision stands. Teammates post recommendations. Only the leader records a decision, which names the winning tasks and the reason. If the leader records another, the newest one stands.
What can go wrong
The most common problems:- The board is empty under
auto. The agent decided to work alone. Useonwhen you want a team regardless. - Two teammates overwrote one file. The brief didn’t give each piece its own path. Name a distinct output path for every piece.
- The cost is higher than expected. Every teammate runs its own model calls. Use a team only for substantial parallel pieces, and check the session’s cost in Usage and cost.
Every team error
Every team error
Limits
See Limits for every product limit.
Next steps
Research team tutorial
Run a research team session end to end.
Multi-agent
Delegation, rosters, inheritance, and limits.
Usage and cost
See what a team session cost.
Deliverables and artifacts
How team outputs are kept.