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 14 CLIs de agentes que o AgentsRoom suporta (Claude Code, Codex CLI, GitHub Copilot CLI, Cursor e mais 10). 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, GitHub Copilot CLI, Cursor e outras 10 CLIs de agentes) 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 também são sincronizadas com sua conta: sua biblioteca segue você de máquina em máquina, com ~/.agentsroom/teams/ como cache offline. Os modelos inclusos ficam locais: cada máquina os instala no próprio idioma.

O estado da execução é persistido em disco em {workspace}/.agentsroom/team-runs/{runId}/ (state.json, NOTES.md, inbox/, timeline.jsonl), com escritas atômicas e notas append-only. Uma execução interrompida é 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 execução cuja equipe foi excluída é fechada automaticamente em vez de ficar largada para sempre.

Sim. Cada execução é independente, identificada pelo seu runId. Você pode ter três equipes diferentes rodando em três tickets do mesmo projeto. Dentro de uma execução, o fluxo segue seu grafo: sequencial por padrão, paralelo onde você desenha ramos paralelos (por exemplo QA e Segurança revisando juntos), sempre com uma junção determinística.

Sim. Trace duas ligações sem condição a partir de um nó e os dois destinos rodam como ramos paralelos, cada um em seu próprio agente e terminal. Os ramos têm um nó de profundidade e precisam convergir para um nó de junção comum, o que o editor valida antes de deixar você rodar. Quando todos os ramos terminam, a junção 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).

Você digita um comando de shell no nó, por exemplo npm test, e opcionalmente um nome de flag (checkPassed por padrão). Quando o agente sinaliza o fim da etapa, o AgentsRoom executa o comando no workspace com teto de cinco minutos. Código de saída 0 escreve true na flag, qualquer outro escreve false, sobrescrevendo o que o agente declarou sobre si mesmo. Em caso de falha, os últimos kilobytes de saída viajam ao próximo agente: a volta aterrissa com o stack trace real, e o resultado aparece na timeline da execução.

Sim. Cada nó pode fixar skills da sua Skills Library, de projeto ou globais. O agente recebe a instrução de carregá-las antes de começar a etapa: uma checklist de revisão, um runbook de deploy ou um procedimento de teste é aplicado em cada execução, em vez de depender da memória do agente.

Sim. O editor executa um conjunto de verificações do grafo e separa os erros bloqueantes dos avisos. Os erros param a execução: um nó Start ou End ausente, conexões duplicadas, duas conexões com as mesmas condições, uma conexão cujas condições se contradizem, um fan-out inválido. Os avisos não: um nome de flag com espaços em volta, uma condição numa conexão que sai do Start, um nó cujas conexões de saída são todas condicionais, onde a execução pode parar. Ambos aparecem num painel de verificações e as conexões culpadas são recoloridas no canvas, então você corrige o grafo antes de perder uma execução com ele.

Não, e isso é proposital. Enquanto uma execução está viva, a definição da equipe fica congelada contra escritas vindas das ferramentas MCP: nós, ligações, teto de ciclos, instruções de etapa, skills, comando de verificação, papel, provedor e modelo são somente leitura para os agentes, uma skill carregada pela execução também não pode ser reescrita, e o congelamento não se contorna excluindo e recriando a equipe. Um agente não deve reescrever a regra que o governa. Você continua editando tudo pela interface a qualquer momento.

Sim. O companheiro mobile consegue iniciar uma equipe em um projeto, mostra um banner de execução com o progresso de cada etapa e dá acesso ao terminal do agente que está trabalhando no momento. A execução em si continua rodando no seu desktop, pelas CLIs reais, exatamente como se você a tivesse iniciado por lá.

Pergunta em que é que o run iria falhar. Se fosse falhar por perder o fio, escolhe o revezamento: uma só sessão interpreta todos os papéis e nunca volta a explicar uma decisão a si própria. Se fosse falhar por concordar consigo próprio, escolhe a equipa: os papéis correm como agentes separados, portanto quem revê o código não é quem o escreveu. O revezamento é o predefinido porque é o que já faz toda a equipa construída antes de esta definição existir, não porque seja melhor.

Não. Um colega arranca na primeira vez que é preciso, seja porque o grafo chega ao passo dele, seja porque outro agente lhe escreve, e a partir daí fica vivo até ao fim do run. Uma equipa de quatro papéis não queima quatro sessões para responder a uma pergunta que só diz respeito a dois, e um papel a quem se fala no terceiro ciclo continua a ser o mesmo agente que respondeu no primeiro.

Só daquilo que consegue ler. Um colega que entra a meio do run tem a sua própria sessão e nenhuma memória do trabalho, e é exatamente por isso que a opinião dele vale alguma coisa. Põe-se a par através das notas partilhadas, da linha do tempo do run e do diff do git desde o início do run, tudo isso lido com as suas próprias ferramentas. Essa leitura é o custo do modo, e é a razão pela qual o modo revezamento continua a existir.

Sim, e é assim por predefinição. Com a conversa livre desligada, um colega só pode escrever aos papéis para os quais o seu nó aponta no grafo, portanto não se contorna um portão perguntando a outra pessoa. Liga-a quando quiseres uma equipa a sério: qualquer um escreve a qualquer um, em qualquer direção e a vários ao mesmo tempo. De uma forma ou de outra, o grafo continua a iniciar o run e continua a terminá-lo.

Sim. Um gatilho pode apontar para uma equipa em vez de um agente sozinho, por isso o mesmo pipeline corre sem supervisão: num ritmo de calendário, na janela de quota do teu plano de IA, ou num evento enviado pelo GitHub, GitLab, Slack, Linear, Sentry ou pela tua CI. O prompt chega ao primeiro passo da equipa, o run acontece na tua própria máquina como qualquer outro, cai no histórico do gatilho, e uma notificação avisa-te de que arrancou. Os gatilhos vivem no painel Gatilhos do projeto, ao lado das tarefas agendadas.