Skip to main content
One session can split work across several agents. The agent you start, called the root, can hand a focused task to a child agent, run a team of copies on a shared task board, or ask an advisor for a second opinion. Every agent in the tree works in the same sandbox, and cost rolls up to the root. This page covers choosing a pattern, delegation, the roster, what a child inherits, limits, and how to inspect the tree. For the shared task board, see Teams. The TypeScript samples assume the rl client from Client setup.

Before you begin

  • To create agents and start sessions, you need the Developer or Admin role in the organization. The User role can read session trees and threads. See Organizations and roles.
  • You need an agent and an environment. See Agents and Environments.
  • Every session can delegate to copies of its own agent without any setup. You only need a roster to delegate to other agents or to add an advisor.

Choose a pattern

Start with one agent. Add agents only when the work splits into pieces that don’t depend on each other. A piece is worth a separate agent when it has its own build-and-test loop, its own sources, or its own approach to evaluate. Splitting a short, sequential task across agents costs more and usually finishes later, because each child starts without the parent’s context.
Delegation and teams combine. A team member can still delegate a focused sub-task, within the depth limit.

How delegation works

The root delegates with the delegate_subagent tool, which you see in the transcript. Each child is a separate session with its own conversation, called a thread. What to expect:
  • The task must stand alone. A child receives only the task text, not the parent’s conversation. Name the files, the goal, and what a good result contains.
  • Hand work over by file path. Children share the root’s sandbox and environment, so a child can read what the parent wrote and the parent can read what the child wrote.
  • Children report a result. A child finishes with submit_result and a status of done, partial, or blocked, a summary, and the paths it produced. The parent reads exactly that summary.
  • Threads stay reachable. After a child reports, the parent can send it a follow-up with send_to_agent, and the child continues with its earlier context. The parent can also wait for children with wait_for, stop one with interrupt_agent, and close an idle one with archive_thread.
  • Failures stay contained. A child that fails, or a roster agent that can’t be resolved, returns an error to the parent. Its siblings keep working.
  • Everything is inspectable. The console session page and the API show every child session, its thread, and a merged timeline. See Inspect the session tree.

What a child inherits

What a child can use depends on who the child is. A copy of the root acts as the root under another name. A different agent from the roster is its own principal and gets only what its own definition grants. Two rules apply to credentials across the whole tree:
  • Environment-variable credentials come only from the vaults granted to the root session. They’re set as plaintext environment variables in the shared sandbox when it starts, every agent in the tree can read them, and nothing adds to them later. If a roster agent’s own vaults hold environment-variable credentials that the root doesn’t have, the child’s log shows a session_status warning with the code delegated_env_credentials_unavailable and the missing variable names. To make a variable available, grant its vault to the root session.
  • MCP server credentials work for each agent individually. A roster agent’s MCP servers authenticate with its own grants, and the root’s credentials never authenticate a roster agent’s servers.
The shared sandbox holds the root’s environment-variable credentials, and every agent in the tree runs its commands in that sandbox. Don’t rely on a roster agent to keep a sandbox credential away from other agents in the same tree. To share a credential on purpose, attach the same vault to both agents.

Configure a roster

A roster lists the agents a coordinator can delegate to, and at most one advisor. It’s part of the agent version, so a running session keeps the roster it started with. Each roster entry has these fields: This coordinator can delegate to a researcher agent and consult one advisor.
  1. In the sidebar, click Agents, then open the coordinator agent.
  2. On the Configuration tab, find Multiagent.
  3. Click Add subagent, then choose the agent under Subagent.
  4. Click Add advisor, choose the Advisor model, then click Add.
  5. Click Save new version.
The console doesn’t edit delegation limits or entry names. Use the API for those.
The response is the agent with its first version, and the roster under multiagent. Some fields are omitted.
To change the roster later, create a new agent version. A version request replaces the whole definition, so resend every field you want to keep. See Agents.

Use the advisor

The advisor answers questions the agent asks with consult_advisor. It sees a digest of the session’s recent activity and its own earlier advice, and it returns guidance only. It has no tools, can’t read files, and doesn’t do work. Ask the agent to consult it at decision points, for example: “Before you change the schema, consult the advisor with your migration plan.”

Set delegation limits

Limits belong to the coordinator’s roster, not to a session start request. A child carries the root’s limits down the tree. A child agent’s own roster can tighten them but never widen them. When a limit is reached, the delegation is refused with a tool error that the agent reads, such as “3 threads are already running, the most allowed at once”. The agent then waits for a child to report, reuses an idle child, or archives one. The session itself keeps running. max_tree_cost_usd in limits caps what an evaluation run spends; it doesn’t cap an ordinary session tree. To watch spend, see Usage and cost and Analytics.

Inspect the session tree

The tree view shows every session in the tree, every thread, and the first page of one merged timeline. The thread list is the complete list of children, ordered by position in the tree.
  1. In the sidebar, click Sessions, then open the root session.
  2. The transcript shows each child’s work in its own lane.
  3. Open the Work tab to see members, the board, and messages between agents.
Both calls accept any session id in the tree and resolve to its root. A tree response looks like this, with events shortened:
A root with stop_reason awaiting_subagents is waiting on its children, not stuck. When next_event_id is present, read the rest of the timeline with the events API. See Events.

Track cost across the tree

Every child’s model cost counts toward the root session. Read one total for the tree, or a row per session to see which child spent what, with listSessionModelCostNodes and scope=tree. See Usage and cost. Child sessions don’t take a slot under the agent’s max_concurrent_sessions; only root sessions do.

What can go wrong

Limits

See Limits for every product limit.

Next steps

Teams

Run copies of an agent on a shared task board.

Deliverables and artifacts

Where children write outputs and how they’re kept.

Research team tutorial

Run a team end to end with a graded deliverable.

Vaults

Grant credentials to the root and to roster agents.