Team Orchestration is what happens at runtime — how a team routes a message, hands it off to a member, and recovers when things go wrong. Configuration lives on the AI Teams, Team Agents, and Team Manager screens; this page explains what happens when a team runs.
How a User Message Travels Through a Team
The message lands in the team's session, and the Team Manager takes the turn. Its system prompt is assembled from the Team Manager Instructions, the team's language/response preferences, and a freshly built list of delegation tools naming every currently eligible member.
The manager reasons over the conversation and calls a delegation tool: which member, and a written instruction for it.
The platform validates the target (exists, not archived, on this team's roster), records a sub-task hand-off, and runs the member inside the same session.
The member works its own agent loop — its own model, instructions, tools, knowledge, memory, and guardrails — scoped to its sub-task thread.
The member's answer is stored as an internal message and returned to the waiting manager as a structured result; the manager continues — another delegation, a clarification, or the final user-facing reply. (In router/orchestrator-style teams the member's answer goes straight to the user instead.)
The Team Routing Styles
Three, differing in who speaks to the user after routing:
Style | How it works |
|---|---|
Standard (default for teams created in the UI) | Delegation runs on sub-task threads: the member's answer returns to the manager, which composes what the user sees. Follow-ups to the same member reuse the same thread, so the member keeps its working context across turns. |
Router | The manager gets a single route-style tool; the routed member answers the user directly, and the manager's involvement ends once it has routed. Best for pure dispatch ("send billing questions to the billing agent"). |
Orchestrator | Like routing with delegation-style instructions but threadless: each delegation is a fresh interaction, the member's answer is published directly to the user, and the manager is told the response was already published so it should end the conversation. |
Router and orchestrator are platform-configured team types; the screens don't currently expose a toggle. There is also a platform option that presents each member as its own hand-off tool instead of one generic delegation tool — same mechanics, one named tool per specialist.
What a Delegated Member Actually Sees
Only its sub-task thread — not the user's raw conversation. A delegation creates an internal message from the manager to the member inside the same session, carrying the manager's written instruction (and any files the manager passes along, which are attached to that message). When the member builds its context, it reads just the messages of that thread: the manager's instructions and its own earlier replies there. Symmetrically, the manager's context is the main thread — the user's messages and its own — not the members' internal working messages. Messages blocked by guardrails and internal alerts are excluded from everyone's context.
Note: This isolation is why the manager's delegation text must be self-contained — it is the member's entire briefing.
How the Answer Gets Back to the Manager
Through a wait-and-signal hand-back. When the manager delegates on a sub-task thread, its turn parks and waits (up to two hours) while the member runs. When the member finishes, its reply is signaled back and the manager's tool call resolves to a structured result — the member's answer wrapped with the sub-task id, a success/failure status, and a hint to reuse the same id to continue that task. On failure, the result says so explicitly and leaves the decision — retry, fall back to another member, or surface the problem — to the manager. If a member mid-task needs the user (a clarification, a connection choice), that question takes the same hand-back path: the manager receives it as the delegation's result, relays it to the user, and re-invokes the member on the same thread with the answer.
What Keeps a Team From Looping or Spiraling
Several independent brakes:
Brake | What it does |
|---|---|
Invocation cap | A session-wide count of agent triggers; at the limit (60 by default, adjustable via the team's response-generation settings) the run stops with a loop-limit error rather than continuing. |
Error budget | After roughly three errors in a session, the executing agent is instructed to stop using tools and give its best final answer. |
Repetition detection | An identical tool call repeated with the same input is intercepted with an instruction to move on instead of re-running it. |
Safe routing failures | A delegation to a missing or non-member agent returns a failure to the manager instead of erroring the conversation. |
Wait timeout | A hand-back that never arrives times out after two hours instead of hanging forever. |
Can Routing Decisions Be Cached?
Yes — teams support an optional platform setting that remembers query-to-routing decisions. When enabled, a repeated query skips the manager's model call and reuses the earlier routing decision (fresh decisions are stored as they happen). Useful for high-traffic teams where the same questions recur; it trades a little routing freshness for cost and latency.
Which Model Does What in a Team
The Team Manager LLM runs only the manager's turns: reading the conversation, choosing members, writing delegation instructions, and (in the standard style) composing the final reply. Each member runs entirely on its own configured models — response generation, embeddings, guardrail detection, everything — exactly as when working solo. Costs and traces attribute each model call to the agent that made it, all within the team's single session.