Mode B -- Agent Teams

GAIA runs its multi-agent work in one of two execution modes. Mode A is the default: every agent turn runs as a fresh, one-shot subagent that does its job and disappears. Mode B (Agent Teams) is the opt-in alternative: agents run as persistent, windowed teammates that stay alive across the phases of a workflow, keep their working context between turns, and can exchange messages with the orchestrator and with each other.

Mode B is opt-in, and it degrades gracefully.

Mode B's live persistent-teammate behaviour depends on runtime support: background named agents and inter-agent messaging must be available in the environment. The wiring for Mode B is in place across the GAIA skills, but when that runtime support is absent the framework transparently runs the equivalent work as Mode A and emits a MODE_B_FALLBACK notice. Treat Mode B as an enhancement that activates when the substrate supports it -- not as a guarantee that persistent teammates are always live.

Overview

In Mode A, the orchestrator hands each unit of work to a new agent turn. That turn reads what it needs, produces its result, and ends. The next turn starts from scratch. This is simple, predictable, and works everywhere -- it is the default for good reason.

In Mode B, the orchestrator instead stands up a small team of named teammates at the start of a workflow. Each teammate runs in its own window and remains available for the duration of the run. Because a teammate persists, it keeps the context it has already built up, and the orchestrator can route follow-up work to the same teammate rather than re-spawning a cold agent for every step. Teammates can also be addressed by name, which is what makes back-and-forth collaboration possible.

Mode B does not change what GAIA produces -- the artifacts, gates, and review contracts are identical. It changes how the agents are hosted while they produce it.

Mode A vs Mode B

The two modes differ along three axes: how an agent is hosted, what its transcript carries, and how it performs across a multi-phase workflow.

Aspect	Mode A (default)	Mode B (Agent Teams)
Dispatch model	One-shot subagent. Each agent turn runs fresh and ends when the work is done.	Persistent, named teammate. The same teammate stays alive and is addressed across turns.
Transcript	Standard agent transcript -- the turn's own inputs and outputs.	A superset: the standard transcript plus identity metadata (the teammate's name and team) so messages can be routed to and from the right teammate.
Performance	A new agent is spawned per call, so every step pays a cold-start cost.	The teammate persists across phases, so warm context is reused and per-step spawn cost is avoided.
Availability	Works everywhere -- no special runtime support required.	Activates only when the runtime substrate supports background named agents and inter-agent messaging; otherwise it falls back to Mode A.

How to enable

Mode B is opt-in. Nothing changes until you turn it on, and even then it only takes effect where the runtime supports it (see substrate fallback below). There are two levels of control.

Project-level

Set the orchestration mode for the whole project in your project configuration. The orchestration section carries a mode field; setting it to the team value opts the project into Agent Teams as the preferred execution mode:

orchestration:
  mode: team

With this set, GAIA-orchestrated workflows will prefer to run their agents as persistent teammates. If the runtime cannot host teammates, the same workflows run as Mode A and report the fallback -- the project configuration is a preference, not a hard requirement that can fail a run.

Per-skill

Individual skills that orchestrate multiple agents read the same orchestration preference, so the project-level setting flows through to them automatically. A skill consults the resolved mode at dispatch time and routes its agent work accordingly -- as a team of persistent teammates when Mode B is active and supported, or as one-shot subagents when it is not. You do not need to edit each skill: the single project-level preference is the switch, and each skill honours it at the point where it stands up its agents.

A note on honesty.

Turning Mode B on tells GAIA what you prefer. Whether you actually get live persistent teammates depends on the runtime. When the substrate is present you get Mode B; when it is not, you get Mode A with a clear MODE_B_FALLBACK notice. Either way the work completes and the outputs are the same.

Windowed Teammates UX

When Mode B is active, each teammate runs in its own window. This gives the run a different feel from Mode A's single stream of one-shot turns.

Teammate visibility

Every persistent teammate is a named, visible participant. You can see which teammates the orchestrator has stood up, watch each one work in its own window, and follow the conversation between them. Because teammates carry identity metadata, it is always clear which teammate produced a given message or result -- there is no anonymous pool of interchangeable turns.

Human interjection routing

A persistent, named team also gives you a place to step in. Because each teammate is addressable, a human interjection can be routed to a specific teammate -- you can direct a note or a correction to exactly the teammate it concerns, rather than dropping it into a single shared channel and hoping the right agent picks it up. The orchestrator remains the coordination point: it routes your interjection to the named teammate and folds the response back into the workflow.

Known limitations

Mode B is a real capability with real boundaries. Know these before you rely on it.

Eight-teammate ceiling. A team is capped at a maximum of eight concurrent persistent teammates. Workflows that would exceed that are kept within the ceiling -- Mode B does not stand up an unbounded swarm.
Clean-room reviewer exclusion. Review agents are deliberately excluded from the persistent team. A reviewer must run in a fresh, clean-room context with no shared team memory, so that its verdict is independent of the work it is reviewing. Reviewers therefore always run as one-shot agents even when the rest of the workflow is running as a Mode B team -- this exclusion is by design and is not a fallback.
Opt-in fallback to Mode A. Mode B only activates when the runtime substrate supports it. When background named agents or inter-agent messaging are unavailable, the workflow transparently runs as Mode A and emits MODE_B_FALLBACK. The run still completes -- you simply get one-shot agents instead of persistent teammates for that run.

Substrate fallback

The single most important thing to understand about Mode B is that it is an opportunistic enhancement. The orchestration wiring is present throughout the GAIA skills, and it asks the runtime, at dispatch time, whether it can host a team of persistent named teammates that can message one another.

When the substrate is available -- the workflow runs as Mode B: persistent windowed teammates, warm context across phases, addressable for human interjection.
When the substrate is absent -- the workflow runs as Mode A, exactly as it would with no Mode B preference set, and reports a MODE_B_FALLBACK notice so you know the persistent-teammate path was not taken on this run.

This fallback is transparent and lossless: the same artifacts, gates, and review contracts apply in both modes. Mode B never blocks a run and never changes the result -- it only changes how the agents are hosted while they do the work, and only when the environment can support it.