Teams & mesh

In one line. Two ways to compose many runnables when one agent isn’t enough — an in-process Multi-Agent Team (a leader delegating to member agents) and a durable, restart-proof Mesh (a pipeline wiring runnables together by queues). You’ll be able to. Build a 2-member team from the Subagents tab, recognise the Mesh designer, and decide between Team, Mesh, and XFlow for a given job. Where this lives. Studio ▸ Agent Builder ▸ Agents — the same gallery and + Agent picker you already know.

When one agent isn’t enough

One agent is the right answer surprisingly often. Reach for composition only when a single agent genuinely can’t do the job well:

Specialists. The work splits into distinct skills — an extractor, a fraud-checker, a summariser — and you want each tuned and tested on its own, not crammed into one mega-prompt.
Parallelism. Two independent checks (credit and compliance) can run at the same time instead of one-after-the-other.
Long, durable, multi-stage automations. The whole process takes minutes, has branches and joins, and must survive a restart without losing its place.

The platform gives you two tools for this, and they are not the same thing. Learn the difference once and you’ll always pick the right one:

	Multi-Agent Team	Mesh
What it is	One leader agent delegating to member agents	A pipeline wiring runnables by queues
Runs where	In-process, inside one agent run	Durably, across the orchestrator’s bus
Members are	Other agents only	Any runnable: agent, XFlow, mesh, or Service
Survives a restart?	No (it’s one live conversation)	Yes (batons are written to a durable bus)
Reach for it when	Several specialists must collaborate right now	A long, branching, multi-stage automation

Under the hood. A Team is a TeamEx/SequentialFlow built inside a single agent run in the orchestrator. A Mesh is a separate durable runtime (members hand batons over a Postgres-backed bus). That’s why only the Mesh survives restarts — and why a Mesh member, but not a team member, can be an XFlow or a parked Service.

Multi-Agent Teams — the Subagents tab

A Multi-Agent Team is just an ordinary agent that has subagents. You don’t create a separate “team” object — you add subagents to an agent on its Subagents tab, and that agent becomes the leader. In the gallery it still carries the A kind badge (tooltip “Multi-Agent”), and the Kind filter has a Multi-Agent option to find them.

The leader is the agent you’re editing — its Persona and Instructions decide how it delegates and synthesises. Each subagent row adds one member agent, picked from agents in the project. The tab’s empty state reads “Add a subagent to make this agent a coordinator.”

Control	What it does	Notes
Coordination mode	How the leader uses its members	The four modes below. Appears once you have at least one subagent.
+ Add subagent	Adds a member row	Adding the first one turns this agent into a coordinator/team leader.
Agent (per row)	Which existing agent is this member	The dropdown lists team-eligible agents in the project.
Prefix instructions	Extra instructions prepended for this member	Use it to tell one member how to behave inside the team.
Reasoning toggle	Lets this member use extended reasoning	Costs latency; turn on only where it earns its keep.
Remove (x)	Drops the member	Removing the last member makes the agent a plain single agent again.

Member approvals live on the Governance ▸ Approvals tab under Team agents — you can require human approval before the leader hands work to a specific member.

The four team modes

Coordination mode is the single most important choice — it decides how the leader uses its members:

Mode	What the leader does	One-line example
coordinate	Delegates sub-tasks to members, then synthesises their answers into one	“Read this claim” → asks Extractor for fields and Policy-checker for coverage, then writes the recommendation.
route	Picks one member best suited to the request and hands off	A triage leader routes a billing question to the Billing agent, a returns question to the Returns agent.
collaborate	Runs all members in parallel on the same input, then combines	Three reviewers each red-flag a contract at once; the leader merges the flags.
sequential	Pipes output member → member in order	Extract → normalise → summarise, each step consuming the previous one’s output.

Watch out. A team runs as one in-process agent run — it does not survive a restart, and every member is an agent (you can’t drop an XFlow or a Service into a team). If you need either of those, you need a Mesh, not a team.

Build one — a 2-member sequential team

Open Studio ▸ Agent Builder ▸ Agents. Select (or create) the agent you want as leader — say Claims Lead — and click Edit.
Go to the Subagents tab. Set Coordination mode to sequential.
Click + Add subagent. In Agent, pick your first specialist (e.g. Field Extractor). In Prefix, add a line like “Extract every field; output JSON only.”
Click + Add subagent again. Pick the second specialist (e.g. Risk Scorer) and prefix it “Read the extracted fields above and score risk 0–100.”
Click Save Agent. Order matters in sequential mode — Field Extractor runs first, its output feeds Risk Scorer.
Use the Playground pane (right side): send a sample document and watch the leader run the two members in order.

Mesh — the durable pipeline designer

A Mesh is a durable pipeline that wires runnables together by queues. Each node is a member that references any runnable — an agent, an XFlow, another mesh, or a Service — and members hand a small baton (the previous step’s output) to the next over a durable bus. Because the bus is durable, a mesh survives a restart: a baton mid-flight is not lost. That is the whole reason Mesh exists and Teams don’t cover it.

Advanced surface — always available. The Mesh designer is the XFlow designer in mesh mode, not a separate screen. It’s an advanced surface, but it is not flag-gated: + Agent ▸ Mesh is always offered whenever you can add an agent. In mesh mode the palette is reduced to exactly XFlow Operator + Queue + Service (Subscribe/Publish are XFlow-mode pub-sub operators, not mesh tiles), and Save/Run target /api/mesh. Treat this section as “recognise it and understand the model”; most builders ship Teams and XFlows long before they author a Mesh by hand. Intake can also run a mesh even when you didn’t draw one.

From the Agents gallery footer, + Agent opens a three-option picker:

Option	Opens
Agent	The single/team agent builder.
XFlow	The XFlow create dialog → the visual pipeline designer (XFlows & pipelines).
Mesh	The same create dialog in mesh mode — sets `meshMode`, palette = XFlow + Queue + Service, Save/Run → `/api/mesh`.

A saved Mesh appears in the gallery with the M kind badge; selecting it swaps the right pane to the embedded designer in mesh mode. The designer has Mesh and Runs tabs, Save Mesh and Run actions, and a mesh-run status chip; members are the nodes, queues are the boxes between them, and the baton is the output that hops.

Control	What it does	Notes
XFlow Operator node	A member referencing a runnable	The member’s “work” — an XFlow, agent, or mesh.
Queue node	The pipe between members	Node→queue = publish; queue→node = subscribe. Carries the baton.
Service node	A parked member	The member sits `awaiting` while an external worker does long work — see below.
Save Mesh	Persists the mesh	Targets `/api/mesh`. MeshId is global, not per-project — pick unique ids.
Run	Starts a mesh run	Delegates to `runMesh()`; results land in the Runs tab.

Behaviours to know — the 240 s limit, fan-out, fan-in

A member has a 240-second ceiling. If a single step needs longer (a GPU model, OCR on a 200-page scan, an overnight batch, a slow partner API), it cannot be a normal member. Instead, make it a Service (LLMs & services): the member parks in an awaiting state holding no worker, your external program pulls and does the work, then reports back and the member resumes. Parking can wait minutes or hours without tying up platform resources.
Fan-out (1→N). Two members subscribed to the same queue both receive the baton and run in parallel — e.g. score-credit and check-fraud at once.
Fan-in (N→1). One member with two incoming queues waits for both before it runs (a join) — e.g. decide runs only after both credit and fraud have reported.
A run is done when nothing is running, nothing is pending on the bus, and nothing is parked.

                       ┌──────────┐
        document ─────▶│  intake  │ (member: XFlow)
                       └────┬─────┘
                       publishes baton
                    ┌───────┴────────┐  fan-out: both subscribe to the same queue
              ┌─────▼─────┐    ┌──────▼──────┐
              │  score    │    │  check      │   <- run in parallel
              │ (XFlow)   │    │  fraud      │
              └─────┬─────┘    │ (Service)   │   <- parks <=24h, external worker does it
                    │          └──────┬──────┘
                    └──────┬──────────┘  fan-in: decide waits for BOTH
                       ┌───▼────┐
                       │ decide │  (member: agent) -> writes the doc Summary
                       └────────┘

Stretch (read-only): open + Agent ▸ Mesh, drop two XFlow nodes and a Queue between them, and read the Mesh vs Runs tabs — don’t save unless you mean to (MeshId is global). The goal is to recognise the surface, not ship a mesh.

How a team or mesh is run and observed

A Team runs whenever its leader agent runs — from the Playground, as a collection’s intake agent, or wherever a single agent would run. There’s no separate “team run”; you observe it on the leader’s Runs tab and watch the member hand-offs live in the Playground transcript.
A Mesh runs from Run in the designer, or as a collection’s intake runnable (intake routes by kind: mesh → agent → xflow). Observe it on the designer’s Runs tab in mesh mode: you get a Mesh run list (status / run-id / doc / hops) and a readable Run trace — a member timeline with per-member states (done / failed / running / awaiting service), per-member Show output / View full logs, a queue-health banner (queued vs stalled), and a Baton trail of pub/sub hops (delivered / queued / failed, with expandable payloads and attempt counts).

For observing agent, xflow, and mesh crews as they run, see Crew & evaluations.

Tip. The awaiting service dot in a Run trace is your friend: it tells you a member is parked on a Service and waiting on your external worker, not stuck. The Baton trail shows exactly which hop is in flight.

Team vs Mesh vs XFlow — which do I reach for?

Need	Use	Why
One job, several agent specialists collaborating now	Multi-Agent Team	In-process delegation; fastest to build (just the Subagents tab).
Deterministic, multi-step processing of each document (python, SQL, API, agent call)	XFlow (A10)	A single pipeline of operators; no durable cross-runnable wiring needed.
Long, branching, multi-stage automation that must survive restarts	Mesh	Durable bus; members fan-out/fan-in; members can be XFlows/agents/meshes.
Any step over 240 s (GPU/OCR/overnight/slow partner API)	Mesh + Service (A2)	The member parks while an external worker pulls and does the work.
Pick one of several agents per request	Team (route mode)	Leader routes to the single best member.
Two independent checks at the same time, then a join	Mesh (fan-out → fan-in)	True parallel members with a durable join.

Watch out. Don’t reach for a Mesh just because you have “several agents.” If they collaborate inside one conversation and don’t need durability, a Team is simpler. Mesh earns its complexity only when you need durability, cross-runnable members, or true parallel fan-out/fan-in.

Where to go next

Library & bots — the reusable Python assets and RPA workers that mesh nodes and tools draw on.
Your first agent — a single agent’s anatomy, including the Subagents tab.
XFlows & pipelines — the pipeline primitive and the Runs tab in depth.
LLMs & services — long-running external work via parked Services.