> ## Documentation Index
> Fetch the complete documentation index at: https://vetta.sh/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Context & budgets

> What sessions share, what stays isolated, what a member holds while it runs, how spend flows across a team, and the cross-thread events.

A team is a set of [sessions](/docs/team/delegation) 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

<CardGroup cols={2}>
  <Card title="Isolated per session" icon="split">
    Tools, MCP servers, model, harness, system prompt, [skills](/docs/capabilities/skills), and — most importantly — conversation context. Each member reasons over only its own turns and the brief it was handed.
  </Card>

  <Card title="Shared across the team" icon="link">
    The [team board](/docs/team/board), when it is enabled — one board per agent, readable and writable by every session on the team. [Vault](/docs/identity/vault) credentials. And a [micro-VM](/docs/computer/index) filesystem, *conditionally* — see below.
  </Card>
</CardGroup>

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.

<Warning>
  **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.
</Warning>

## 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](/docs/concepts/harnesses) publishes it per harness.

Because a team may [mix harnesses](/docs/team/rosters-and-versioning#mixing-harnesses), that decision is made **per member, at spawn**, from the member's own harness — never from its role on the team:

| The member                                                    | What it gets                                                                                                                                                   |
| ------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| An `isolate` harness                                          | **No machine, ever.** It bills storage only, whatever the coordinator holds.                                                                                   |
| A `sandbox` harness, under a coordinator that holds a machine | It **joins** the coordinator's machine. One filesystem, one bill, one concurrency slot for the pair.                                                           |
| A `sandbox` harness, under an `isolate` coordinator           | Its **own** machine, which it owns and which is released when its session ends. An `isolate` coordinator has none to lend, and the member genuinely needs one. |
| A hosted loop whose toolset asks for no sandbox tools         | No machine. A loop that can call none of them should not pay the floor cost of one.                                                                            |

<Note>
  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.
</Note>

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](/docs/concepts/budgets)** 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.

```bash CLI theme={"system"}
vetta agent spend release-manager --by component   # coordinator + every delegated session
```

<Warning>
  Fan-out multiplies concurrent spend. A coordinator running several members at once can burn budget quickly — the pre-flight [budget gate](/docs/concepts/budgets) still refuses any call that would breach the cap, and the [concurrency limit](/docs/team/delegation#bounds) bounds the blast radius.
</Warning>

## 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`.

| Event               | When it is emitted                                             | Carries                           |
| ------------------- | -------------------------------------------------------------- | --------------------------------- |
| `thread.created`    | A member session was spawned.                                  | `thread_id`, `agent_id`, `member` |
| `thread.idle`       | A member's result arrived and was folded into the coordinator. | `thread_id`                       |
| `thread.terminated` | A member session **failed to start**.                          | `thread_id`, `member`, `error`    |

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.

<Note>
  **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`](/docs/team/delegation#typed-results). `thread.idle` is how the event log records that it landed.
</Note>

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](/docs/concepts/events-and-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](/docs/concepts/sessions#stop-reasons) 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.

<Card title="Back to the team overview" icon="network" href="/docs/team/overview">
  The two coordination mechanisms, and the coordinator model at a glance.
</Card>