Build a team

Use a team when several agents with distinct responsibilities should answer one request together. If the work is a fixed sequence with predictable data flow, a pipeline may be the simpler choice.

Define the outcome

Before adding members, write down the team's input, expected output, and completion criteria. This is the contract the whole team is judged against.

Choose a work style

Open Teams and choose New Team. Under Advanced Team Behavior, Work style decides how a request is broken up and how member output is recombined:

• One agent handles it — send each request to a single agent;
• Agents work one after another — each agent builds on the previous response;
• Plan first, then divide the work — a planning step assigns parts of the work to the team;
• Review before answering — add a review step before the final answer;
• Split the work, then combine it — run similar work in parallel, then merge the answers.

The same panel sets Max agents at once and Final check, which decides when a run may finish:

• Check the final format validates the otherwise successful final result against the team's saved output schema.
• Require every step to finish checks only that every child reached the completed lifecycle state. It does not validate any child's output.
• No extra checks leaves the completed run marked Not checked.

There is no separate coordinator agent to appoint. The work style is what coordinates the team.

Add focused members

Select agents whose responsibilities do not overlap unnecessarily. Role on each member is an optional free-text label — use it to say what that agent is there for, not to grant it authority over the others.

Members should perform bounded specialist work rather than compete to solve the entire task.

Define the team contract

Under Advanced Team Contract, set the input and output formats the team accepts and returns. Contracts use the supported, object-rooted subset of JSON Schema Draft 2020-12 and are rejected at save time if invalid. A team with a declared output schema can use Check the final format; without one, that check has nothing to verify.

The final answer must be one exact JSON object. Validation does not coerce types, insert defaults, or discard extra fields. Extra properties remain valid unless the schema declares "additionalProperties": false. Only local # references are supported.

Provider-native structured generation is an aid. Guest Machines validates the final JSON against the original team schema, and a mismatch fails the run with a failed result check. A passing check proves the result's structure—not its facts, reasoning, or fitness for the task.

Test coordination

Run the team with representative input and inspect the resulting call tree and Result checks. Look for redundant calls, circular delegation, unclear handoffs, member output that cannot be combined cleanly, and schema failures at the exact recorded path.

Tighten individual agent contracts before adding more members.

Trigger the team

A schedule or an inbound webhook can start a team the same way it starts a single agent. Create the trigger under Schedules or Inbound Webhooks and choose the team as its target, or from the Triggers section of the team's own page, which fills the target in for you. A trigger has exactly one target — an agent or a team — and the target is fixed once the trigger exists.

If the trigger provides files, each file's short name must match a file assignment saved on the team. The trigger form shows the accepted names and stops you from saving a file that no member would receive.

Triggered runs are unattended, so the team is checked when the trigger is created. A trigger that could not do useful work is refused there rather than left to fail every time it fires:

• A member's high-risk tools have no standing pre-approval. The error names the members and the tools each one needs granted. Without that grant, a member parks its child run for plan approval every time the trigger fires, and the team cannot observe that park — the child expires as a straggler timeout after the run has already spent its budget, so the trigger reads as broken rather than blocked. Edit each named agent and, under Unattended autonomy, either pre-approve the tools it needs or remove them from its toolbox. A tool you cannot see is counted rather than named — whoever owns that member has to grant it.
• The team has no active members. A run would start with nothing to execute. Add an active member first. An inactive team is refused for the same reason.

The check runs at creation. Changing what a member may do unattended afterwards does not revisit existing triggers, so review a team's triggers when you revoke a grant.

A team run fans out, and it regularly takes longer than a trigger waits for the outcome. A trigger whose last run reads Running is reporting that the run was still going when the trigger stopped waiting, not that anything failed. Read the outcome from the run itself — see monitor runs. Running does not count toward the consecutive failures that auto-pause a trigger.

Deleting a team is refused while a schedule or inbound webhook still points at it. An agent's triggers are removed with the agent; a team's are not, because deleting the team would quietly break work someone configured against it. Delete those triggers first, or recreate them against another target and then delete the originals.