Skip to main content
A team is a set of sessions running under one coordinator. This page is the reference for what those sessions share, what each of them costs, and how you observe them.

​
Shared vs isolated

Isolated per session

Tools, MCP servers, model, harness, system prompt, skills, and — most importantly — conversation context. Each member reasons over only its own turns and the brief it was handed.

Shared across the team

The team board, when it is enabled — one board per agent, readable and writable by every session on the team. Vault credentials. And a micro-VM filesystem, conditionally — see below.
The split is deliberate: shared state lets members collaborate on real artifacts, while isolated context keeps each member’s window small. That combination is what makes delegation cheaper than one giant transcript.
The sandbox is not unconditionally shared. Whether a member joins the coordinator’s machine, buys its own, or has none at all depends on that member’s harness and toolset. If your design assumes one filesystem across the whole team, read the next section — a vetta-harness member has no machine to share, by design.

​
What a member holds while it runs

A harness declares an execution mode, and that is the field that decides what a session holds between turns — separately from where the loop runs. isolate runs the loop in the session object itself, so a session between turns holds no machine and bills storage only. sandbox runs the agent as a process on a micro-VM, which the session holds across turns. The harness catalogue publishes it per harness. Because a team may mix harnesses, that decision is made per member, at spawn, from the member’s own harness — never from its role on the team:
This is measured, not designed-for. A production run of a mixed team had the pi member holding its own micro-VM while the vetta member ran with no machine at all — the same team, the same run, two different cost profiles, decided by each member’s harness.
That is also the practical reason to reach for an isolate member on long-horizon work: a member that spends most of its life parked costs very differently on isolate than on sandbox.

​
How budget flows

  • The coordinator’s budget bounds the whole team — every delegated call draws from the same organization balance.
  • Every call in every session is quoted pre-flight. A member cannot spend past the org balance or the coordinator’s max_task_usd, no matter how many members fan out.
  • Because delegation isolates context, downstream calls carry far fewer tokens, so a well-factored team completes the same work for less than a single agent dragging its full history through every turn.
  • Board reads and writes are ordinary tool calls and are metered like any other.
CLI
Fan-out multiplies concurrent spend. A coordinator running several members at once can burn budget quickly — the pre-flight budget gate still refuses any call that would breach the cap, and the concurrency limit bounds the blast radius.

​
Events

The coordinator’s own event stream carries a condensed, cross-session view alongside its ordinary events. You can read it with vetta session events or follow it with vetta session stream. Those three are the whole set a team emits. The event enum also carries thread.running, which nothing writes today — if you are matching on the enum exhaustively, handle it, but do not wait for it.
A member’s result is not carried by an event. It folds back into the coordinator’s transcript as the tool result of the send_to_agent call that started it — free-form text, or the typed structured_output when the delegation supplied an output_schema. thread.idle is how the event log records that it landed.
Every member session is an ordinary session with its own event stream, so you can also drill into a single member’s turns directly. See Events & streaming for the base event shapes and resumable seq semantics.

​
What a parked coordinator does

A coordinator that has fanned out parks with the awaiting_delegation stop reason rather than polling. It wakes when the fan-out it was waiting on is complete — or earlier, if something arrives that is not a delegation result: a person steering it, or a member’s board write, which is a thing the coordinator may want to act on long before that member’s session finishes. The saving is real: a fan-out of four would otherwise cost four model calls, three of which could only conclude that three members are still running.

Back to the team overview

The two coordination mechanisms, and the coordinator model at a glance.