Introduction

A Team composes two or more Agents under a single lead and a coordination mode. You post one prompt to the Team; the lead — not you — decides who reads it first, whether that's routing it to one member, delegating pieces of it to several, or breaking it into a plan the Team works through over several steps.

How this fits together

Coordination mode decides how the lead and members work together on a request — see Coordination modes below.
The lead is the one thing every Team has, in every mode — see The lead below.
Running a Team — sending it a prompt and getting a response back — is documented in the API Reference → Teams: run synchronously, stream, cancel a run, run async, and get or cancel an async job.

Coordination modes

Canonical ID	Studio label	What it does
`handoff`	Route	The lead picks one member to answer, and that member's response is returned directly — no synthesis step.
`dynamic_delegation`	Delegate & Synthesize	The lead breaks the request into subtasks, delegates them to members, then synthesizes their replies into one response.
`parallel`	Parallel Fan-out	The lead sends the same request to every member at once, then synthesizes all of their replies into one response.
`plan_execute`	Plan & Execute	The lead breaks a goal into a task list and works through it, iterating as needed up to a cap, then reports whether the goal was completed.

This is a description of what each mode does for the person calling the Team, not how it's implemented internally — a Team's coordination mode is set once, when the Team is built.

The lead

Every Team has exactly one lead, in every mode — there's no leaderless Team. The lead is either:

Managed — an LLM configuration and instructions owned by the Team itself, with no member agent behind it. Cheap: a routing or delegation decision doesn't drag a full agent's tools, knowledge, or skills into every turn.
A promoted member — one of the Team's own member Agents, acting as lead with its own tools, knowledge, skills, memory, and budget cap. Useful when the decision of who should handle this itself needs a tool call — checking a customer's tier before routing, for example.

You never choose who answers. You post a prompt to the Team; the coordination mode and the lead's own configuration decide who reads it first — now, and in every future run. There is no caller-supplied entry point on any endpoint this section documents.

Conversation memory

A Team remembers the conversation it's in. Each time the lead answers, it's shown the earlier messages of that chat session as well as the new one, so a follow-up like "and the second one?" makes sense to it. This is on for every Team by default.

In the Team builder's Behaviour step you can turn it off, so every message is answered as if it were the first, or change how many earlier messages the lead sees (default 5, up to 100). Each message counts once, so a question and its answer are two. More history makes each run cost more.

This is the lead's own memory. Whether members also see the conversation is a separate toggle, below.

Behaviour toggles

Five toggles shape how the lead and members exchange context during a run. All five are Studio builder configuration — set once when the Team is built — not parameters on any endpoint below.

Toggle	What it does
Auto-determine per-member input	The lead tailors what each member actually receives, instead of forwarding the same raw prompt to everyone.
Members see full team history	Each member's context includes the whole Team conversation so far, not just its own subtask.
Share member interactions	Members can see each other's responses within the same run.
Add team name to context	The Team's name is included in the context every member and the lead receive.
Add date/time to context	The current date/time is included in the context every member and the lead receive.

Approvals

In the Team builder's Budget & policy step, Human-in-the-loop approval decides when a run waits for a person:

Choice	What happens
Never	Runs never wait.
When a run's cost reaches $…	You enter a cost limit per run. The run's cost is estimated between steps; once it reaches the limit, the run waits for approval before its next step. It asks once.
Always	Every run waits for approval before it starts.

When approval is on, choose who approves: tick All organization admins, add members by name or email, or both. Save is refused until someone is chosen, and until the cost limit is above 0.

Requests appear in the reviewers' Reviews inbox. Approve and the run continues; reject, or leave it unanswered for 24 hours, and the run ends as failed.
Reviewers are checked when a request is created. A member who has left the organization, or can no longer open reviews, is skipped. If nobody is left, the request goes to the organization's owners and admins.
A step already under way is not interrupted: one long delegation, or several tool calls from one lead turn running together, can take a run well past the limit before it asks.
The estimate covers model tokens only, priced at each member's and the lead's configured primary model the way billing prices them. A model with no price counts as $0, so it cannot trigger the limit. The estimate only decides when to ask; what you are billed is worked out separately.
A limit of 0, set through the API or a Package, asks before the first step; Studio requires more than 0.
If the Team also has an iteration threshold (set through the API or a Package), a run still asks only once.
Teams saved before this change with "Above $10 per turn" now ask once a run reaches $10, and the requests go to the owners and admins until you choose reviewers.
If the organization has no active owner or admin and no chosen reviewer can answer, no request is created and the run ends as failed.
A Team exported to a Package keeps All organization admins but not the chosen members: they belong to your organization, not the one installing the Package.

Policies in a Team run

A Team run follows the Team's effective policy: the Organization's and the Project's policies, plus the ones attached to the Team. A member Agent's own policies count in two places only:

Rule	Decided by
Which of a member's tools it can use	The Team's effective policy and the member Agent's own, strictest wins: a tool that either one forbids is removed before the member runs.
Each tool call as it is made: tool ceilings and the host allowlist	The member Agent's policies: the Organization's, the Project's and the Agent's own. The Team's host allowlist does not apply to its members' tool calls.
Approval requirements, model and region checks, data rules, and the host allowlist for model providers	The Team's effective policy only. A rule attached only to a member Agent does not apply in a Team run.

Every decision is logged against the Team run, so the Policies Activity tab lists it under the Team, not under the member.

To apply a rule to everything a Team does, attach the policy to the Team, its Project or the Organization. A policy attached to a member Agent covers that Agent when it runs on its own, and only narrows its tools inside a Team. See Policies for what a policy can do.

Managing Teams from the API

Teams can be listed, created, read and updated with an API key — see API Reference → Teams. The fields are the settings described on this page. Deleting a Team is done in Studio.

Where to go next

List, create, get and update a team — /api/v1/teams.
Run team (synchronous) — POST /api/v1/teams/{teamId}/run-sync.
Run team (streaming) — POST /api/v1/teams/{teamId}/run-stream.
Cancel team run — DELETE /api/v1/teams/{teamId}/runs/{runId}.
Run team (async) — POST /api/v1/teams/{teamId}/run-async.
Get team job — GET /api/v1/team-jobs/{jobId}.
Cancel team job — POST /api/v1/team-jobs/{jobId}/cancel.

Introduction

On this page