Introduction

A Team composes two or more delegate-eligible 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 the public API surface covered in this section: /run, /run-stream, /run-async, and /jobs.

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.

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.

What this section does not cover

Creating, editing, or deleting a Team; configuring its lead, members, coordination mode, or behaviour toggles; or its budget and policy settings. Those are Studio-only actions — see the Team Builder in Studio — not part of the public API.

Where to go next

Run (synchronous) — POST /api/v1/teams/{teamId}/run-sync, plus cancelling a run.
Run (streaming) — POST /api/v1/teams/{teamId}/run-stream.
Run (async) — POST /api/v1/teams/{teamId}/run-async.
Team jobs — poll and cancel an async run.