An AI Team is a group of agents that work together under a manager, letting several specialists handle one conversation as a single coordinated unit.

Overview

An AI team is a group of agents that work together — "specialized AI teams that work together to streamline workflows." A team has member agents (each good at something specific) and a Team Manager that decides which member handles a request. You build a team much like an agent: give it an identity, add members, configure its manager, and set the same kinds of guardrails, models, knowledge indexing, and response settings. Teams are managed in the AI Teams area, separate from individual agents.

Creating a Team

On the AI Teams list, use New Team (hidden unless your role has create permission on AI Agents). The create flow has two steps:

1. Basic details — "Create specialized teams that work together to streamline workflows." Set the team's Name, Avatar, Workspace, and Tags, then Next.

2. Add agents — "Add Agents to {team}" — "Select agents you wish to add to this team." Pick the member agents from the grid, then Create.

The new team opens in its workspace, ready to configure. Like a new agent, it starts from your workspace's default settings.

What's on the Teams List

Each row shows the Team Name, Agents (how many members it has), Tags, Owner, and Last Updated; a Workspace column appears when viewing across projects. Search with Search teams. Each row's actions are Edit, Clone, Share, and Delete. If you have none yet, the empty state reads Create Teams — "Create specialized AI teams that work together to streamline workflows." Deleting asks you to confirm because it can't be undone.

Note: Created On and Last Updated By columns are also available, hidden by default — reveal them from the column-visibility control, or hover the Last Updated date for the same detail.

What Sections a Team Has

Open a team and you land on a tabbed detail view with the same three top tabs an agent has — Configuration, Deployments, and Observability. Deployments only appears if your role grants deploy access, and Observability only if it grants observability access.

Configuration holds the side-nav, much like an agent's:

Observability holds Sessions and Traces — and only those two. The Spending, Usage, Memories, and Evaluation views an individual agent has are not available for a team.

The team's identity (name, avatar, tags) is edited from the team header. Because guardrails, models, indexing, pre-processing, response generation, sessions, traces, and versions work exactly as they do for an agent, see those screens for the details.

Deploying a Team

Yes, a team has its own Deployments tab, which works exactly like an agent's: create a deployment with New Deployment, pick the deployment type, pick the version to release, and switch it between Live and Paused from its row. The deployment types and channel setup are the same as for an agent. The tab is hidden unless your role grants deploy access.

Models and Settings

A team configures its AI Models and other settings the same way an individual agent does — per-function model pickers (task detection, embedding, response generation, guardrail detection, and so on), indexing and chunking, pre-processing, and response style. They auto-save as you change them. The team applies these across the work its members do, with the Team Manager coordinating.

What Happens When Someone Talks to a Team

Under the hood a team runs like an agent whose job is delegation. Each user message starts a turn for the Team Manager: it reads the conversation and, instead of a normal working toolset, it is handed delegation tools with the list of currently eligible member names built in. The manager picks a member, writes a self-contained instruction for it, and the platform runs that member inside the same session. The member's answer then either returns to the manager — which composes the final reply to the user — or, in router-style teams, is published straight to the user. The eligible-member list is rebuilt on every turn, so adding or removing members, archiving an agent, or a governance condition changing all take effect on the very next message.

How a Team's Guardrails Relate to Member Guardrails

Both layers apply, each on its own turns. When a team is created, the workspace's global guardrail policy is automatically cloned onto it, and the team's Guardrails section edits the team's own set from there. At runtime, the team's guardrails (merged with workspace-global ones) screen the turns the Team Manager handles — the user's incoming messages and the team's outgoing replies. When work is delegated, the member agent's own guardrails screen that member's model calls and responses, exactly as if the member were working solo.

Note: A routed conversation passes through the team's safety net at the edges and each specialist's safety net in the middle — relaxing a rule on the team does not relax it on a member, and vice versa.

Teams Share One Session

Yes. A conversation with a team is one session — the manager's turns, every delegated member's work, and the internal hand-offs between them all live in the same session, so Sessions and Traces show the whole story in one place. Internally the session tracks which agent is "current": it flips to the member while a delegation runs and back to the manager when the member finishes. Delegated exchanges are stored as internal messages tagged with their sub-task thread, which keeps the user-visible transcript clean while the trace still records every member invocation.

If the Team Has Tasks Defined

If a team has Tasks, invoking the team runs those tasks — each executes with its planning setup (automatic planning from instructions, or manual per-step agent assignments) instead of the manager free-form routing each message. With no tasks defined, the Team Manager routes every message as it arrives.