Agent Teams.
Uma verdadeira equipa tech, com script.

Os subagents Claude são delegações inline de uma sessão Claude pai única. O pai decide quando chamar um subagent, o subagent corre numa janela de contexto isolada, devolve um resultado, e o pai continua. AgentsRoom Teams está um nível acima: cada node é uma sessão Claude Code top-level com o seu próprio terminal, o seu próprio estado e o seu próprio scrollback. Vês cada agente correr ao vivo no seu próprio separador, podes falar com qualquer um a qualquer momento, podes pausar a equipa, mudar o workflow e retomar. Não é um substituto dos subagents Claude, podes absolutamente usar ambos. Um node de equipa pode usar subagents internamente.

Funciona com todos os providers suportados pelo AgentsRoom (Claude Code, Codex CLI, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe, Kimi Code). Cada node de equipa escolhe o seu próprio provider e modelo. As tools de coordenação de equipa baseadas em MCP funcionam de forma idêntica em todos os providers porque são expostas através do Model Context Protocol standard. Podes correr uma equipa com Codex no node backend pesado e Haiku no node QA se for o que encaixa com o teu orçamento e a tua latência.

Um objeto estruturado que viaja de um agente para o seguinte. Campos: featureSummary (uma descrição curta do que acabou de ser entregue), changedFiles (git diff name-status), touchedAreas (UI, API, DB, config), risks (qualquer coisa com que o agente seguinte se deva preocupar), testHints (prioridades para o QA), flags (booleanos como qaPassed, usados pelos edges condicionais). O agente chama team_complete_step com este payload, o runner valida-o do lado do servidor, o agente seguinte recebe-o como o seu contexto inicial.

Sim. Quando um node é re-entrado (cycle maior que 1), AgentsRoom não spawna um agente novo. Reutiliza o agente original do cycle 1, escreve o novo payload de handoff diretamente no seu terminal existente, e o agente mantém toda a sua memória de sessão Claude dos cycles anteriores. Isto é crítico: um agente Dev que já sabe o que o QA sinalizou da última vez corrige o bug. Um agente Dev fresco sem memória repetiria simplesmente o mesmo erro.

A config da equipa tem um guard de max-cycles, por defeito 3. Quando o tecto é atingido, o run pausa com estado 'blocked' e espera por ti. Podes finalizar o run, fazer mais um handoff manual, ou cancelar tudo. Sem loops infinitos, sem faturas surpresa de um dia para o outro.

Sim. A equipa corre num workspace único e numa branch única (ou worktree se usares a feature Worktrees do AgentsRoom). Cada agente vê o trabalho do anterior através do git. O payload de handoff inclui um diff git contra a baseline do run para que o agente seguinte saiba exatamente o que é novo.

Não. Teams faz parte do AgentsRoom. Trazes as tuas próprias keys de provider (Claude, Codex, OpenCode, Antigravity, Aider, Grok Build, Mistral Vibe, Kimi Code) e pagas só pelos tokens que usas, como com um agente único. Correr uma equipa Dev para QA num ticket pequeno tipicamente custa o mesmo que correr um agente Fullstack único, porque Haiku/Sonnet no passo de QA é barato.

Equipes de projeto vivem com a room, sincronizadas com sua conta e em cache em {project}/.agentsroom/teams-cache.json (gitignored). Equipes globais tambem sao sincronizadas com sua conta: sua biblioteca segue voce de maquina em maquina, com ~/.agentsroom/teams/ como cache offline. Os modelos inclusos ficam locais: cada maquina os instala no proprio idioma.

O estado da execucao e persistido em disco em {workspace}/.agentsroom/team-runs/{runId}/ (state.json, NOTES.md, inbox/, timeline.jsonl), com escritas atomicas e notas append-only. Uma execucao interrompida e retomada ao reiniciar o app: o orquestrador reentra na etapa ativa, reabre o terminal e o agente recupera o contexto pelas notas e pelas ferramentas de equipe. Uma execucao cuja equipe foi excluida e fechada automaticamente em vez de ficar largada para sempre.

Sim. Cada execucao e independente, identificada pelo seu runId. Voce pode ter tres equipes diferentes rodando em tres tickets do mesmo projeto. Dentro de uma execucao, o fluxo segue seu grafo: sequencial por padrao, paralelo onde voce desenha ramos paralelos (por exemplo QA e Seguranca revisando juntos), sempre com uma juncao deterministica.

Sim. Trace duas ligacoes sem condicao a partir de um no e os dois destinos rodam como ramos paralelos, cada um em seu proprio agente e terminal. Os ramos tem um no de profundidade e precisam convergir para um no de juncao comum, o que o editor valida antes de deixar voce rodar. Quando todos os ramos terminam, a juncao recebe um payload fundido: resumos rotulados por papel, riscos e dicas de teste deduplicados, e flags fundidas com uma regra fail-safe (um conflito booleano se resolve em false).

Voce digita um comando de shell no no, por exemplo npm test, e opcionalmente um nome de flag (checkPassed por padrao). Quando o agente sinaliza o fim da etapa, o AgentsRoom executa o comando no workspace com teto de cinco minutos. Codigo de saida 0 escreve true na flag, qualquer outro escreve false, sobrescrevendo o que o agente declarou sobre si mesmo. Em caso de falha, os ultimos kilobytes de saida viajam ao proximo agente: a volta aterrissa com o stack trace real, e o resultado aparece na timeline da execucao.

Sim. Cada no pode fixar skills da sua Skills Library, de projeto ou globais. O agente recebe a instrucao de carrega-las antes de comecar a etapa: uma checklist de revisao, um runbook de deploy ou um procedimento de teste e aplicado em cada execucao, em vez de depender da memoria do agente.