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 every AgentsRoom-supported provider (Claude Code, Codex CLI, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe, Kimi Code). 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, OpenCode, Antigravity, Aider, Grok Build, Mistral Vibe, Kimi Code) 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.