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 unverified.

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 platform's bounded, object-rooted JSON Schema Draft 2020-12 profile 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 locally validates the final JSON against the original team schema, and a mismatch fails the run with failed verification. 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 completion evidence. 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.