Agent Teams.
A real tech crew, scripted.

Claude subagents are inline delegations from a single parent Claude session. The parent decides when to call a subagent, the subagent runs in an isolated context window, returns a result, and the parent keeps going. AgentsRoom Teams is one level above: each node is a top-level Claude Code session with its own terminal, its own state and its own scrollback. You see every agent run live in its own tab, you can talk to any of them at any moment, you can pause the team, change the workflow and resume. It is not a replacement for Claude subagents, you can absolutely use both. A team node can use subagents internally.

It works with all 14 agent CLIs AgentsRoom supports (Claude Code, Codex CLI, GitHub Copilot CLI, Cursor and 10 more). Each team node picks its own provider and model. The MCP-based team coordination tools work identically across providers because they are exposed through the standard Model Context Protocol. You can run a team with Codex on the heavy backend node and Haiku on the QA node if that is what fits your budget and your latency.

A structured object that travels from one agent to the next. Fields: featureSummary (a short description of what was just shipped), changedFiles (git diff name-status), touchedAreas (UI, API, DB, config), risks (anything the next agent should worry about), testHints (priorities for QA), flags (booleans like qaPassed, used by conditional edges). The agent calls team_complete_step with this payload, the runner validates it server-side, the next agent receives it as its starting context.

Yes. When a node is re-entered (cycle greater than 1), AgentsRoom does not spawn a new agent. It reuses the original agent of cycle 1, writes the new handoff payload directly into its existing terminal, and the agent keeps its full Claude session memory of the previous cycles. This is critical: a Dev agent that already knows what QA flagged last time fixes the bug. A fresh Dev agent without memory would just repeat the same mistake.

The team config has a max-cycles guard, default 3. When the cap is reached, the run pauses with a 'blocked' status and waits for you. You can finalize the run, manually hand off one more time, or cancel everything. No infinite loops, no surprise overnight bills.

Yes. The team runs in a single workspace and a single branch (or worktree if you use the AgentsRoom Worktrees feature). Each agent sees the work of the previous one through git. The handoff payload includes a git diff against the run baseline so the next agent knows exactly what is new.

No. Teams are part of AgentsRoom. You bring your own provider keys (Claude, Codex, GitHub Copilot CLI, Cursor and 10 other agent CLIs) and you pay only for the tokens you use, like with a single agent. Running a Dev to QA team on a small ticket typically costs the same as running a single Fullstack agent, because Haiku/Sonnet on the QA step is cheap.

Project-scoped teams live with the room, synced to your account and cached in {project}/.agentsroom/teams-cache.json (gitignored). Global teams are synced to your account too, so your team library follows you across machines, with ~/.agentsroom/teams/ as the offline cache. Seeded templates stay local: every machine seeds them in its own language.

Run state is persisted to disk in {workspace}/.agentsroom/team-runs/{runId}/ (state.json, NOTES.md, inbox/, timeline.jsonl), with atomic writes and an append-only notes file. An interrupted run resumes on app restart: the orchestrator re-enters the step that was active, reopens the terminal, and the agent gets its context back from the notes and the team tools. A run whose team definition was deleted is closed automatically instead of lingering forever.

Yes. Each team run is independent and identified by its runId. You can have three different teams live on three tickets in the same project. Inside a single run, execution follows your graph: sequential by default, parallel where you draw parallel branches (for example QA and Security reviewing at the same time), always merging back on one deterministic join node.

Yes. Draw two unconditional edges out of a node and both targets run as parallel branches, each in its own agent and terminal. Branches are one node deep and must converge on a common join node, which the editor validates before you can run. When every branch has completed, the join receives one merged payload: summaries labeled by role, deduplicated risks and test hints, and flags merged with a fail-safe rule (a boolean conflict resolves to false).

You type a shell command on the node, for example npm test, and optionally a flag name (checkPassed by default). When the agent signals completion, AgentsRoom runs the command in the workspace with a five-minute cap. Exit code 0 writes true into the flag, anything else writes false, overriding whatever the agent reported about itself. On failure, the last kilobytes of output travel to the next agent so the loop-back lands with the actual stack trace, and the result shows on the run timeline.

Yes. Every node can pin skills from your Skills Library, project or global. The agent is instructed to load each one before starting the step, so a review checklist, a deploy runbook or a testing procedure is applied on every single run instead of depending on the agent's memory.

Yes. The editor runs a set of graph checks and separates blocking errors from warnings. Errors stop the run: a missing Start or End node, duplicate edges, two edges carrying the same conditions, an edge whose own conditions contradict each other, an invalid fan-out. Warnings do not: a flag name padded with spaces, a condition on an edge leaving Start, a node whose outgoing edges are all conditional so the run can dead-end. Both are listed in a checks panel and the guilty edges are recoloured on the canvas, so you fix the graph before losing a run to it.

No, and that is deliberate. While a run is alive, the team definition is frozen against writes coming from the MCP tools: nodes, edges, max cycles, step instructions, skills, check command, role, provider and model are read-only for agents, a skill loaded by the run cannot be rewritten either, and the freeze cannot be bypassed by deleting and recreating the team. An agent must not rewrite the rule that governs it. You keep editing everything from the interface at any time.

Yes. The mobile companion can start a team on a project, shows a run banner with the progress of each step, and gives access to the terminal of the agent currently working. The run itself still executes on your desktop, through the real CLIs, exactly as if you had started it there.

Ask what the run would fail on. If it would fail by losing the thread, pick relay: one session plays every role and never re-explains a decision to itself. If it would fail by agreeing with itself, pick team: the roles run as separate agents, so the one that reviews the code is not the one that wrote it. Relay is the default because it is what every team built before the setting existed already does, not because it is better.

No. A teammate starts the first time it is needed, either because the graph reaches its step or because another agent writes to it, and then it stays alive for the rest of the run. So a four-role team does not burn four sessions to answer a question that only concerns two of them, and a role that is addressed on cycle three is still the same agent that answered on cycle one.

Only what it can read. A teammate that joins mid-run has its own session and no memory of the work, which is exactly why its opinion is worth something. It catches up through the shared notes, the run timeline and the git diff since the run started, all of which it reads through its own tools. That reading is the cost of the mode, and it is the reason relay mode still exists.

Yes, and that is the default. With free-form conversation off, a teammate may only write to the roles its node points to in the graph, so a gate cannot be routed around by asking someone else. Turn it on when you want a real team: anyone writes to anyone, in any direction, and to several at once. The graph still starts the run and still ends it either way.