Agent Teams.
Uma verdadeira equipa tech, com script.
AgentsRoom Teams encadeia os teus agentes IA de código como uma verdadeira equipa de engenharia. Um Fullstack Dev entrega a feature, um QA Engineer valida-a, um PM assina. Cada papel tem script, o workflow é visual, e cada handoff transporta o resumo da feature, o diff, os riscos e as pistas de teste. Acabou-se o agente único que faz tudo mal.
Constrói a tua equipa dev IA dos sonhos num canvas visual, tal como um workflow n8n. Edges condicionais, loops de feedback, retries, guard de max-cycles. Guarda uma vez, lança em cada ticket, e vê os teus agentes a passar o testemunho como seniors.
AgentsRoom Teams: editor visual de workflow multi-agente, handoff automático entre agentes Claude Code, loop de feedback Dev para QA, comunicação inter-agente via MCP.
Agent Teams é a resposta do AgentsRoom a uma verdade brutal sobre os agentes IA de código: um agente único que tenta fazer tudo acaba a fazer tudo mal. O agente Fullstack que codifica, testa, faz review, faz deploy e escreve a spec ao mesmo tempo esquece metade das suas instruções pelo caminho. A resposta certa, a que toda equipa de software séria do mundo usa, é dividir o trabalho em papéis. Um developer codifica. Um QA engineer valida. Um product manager assina. Um security reviewer audita. Cada papel tem o seu próprio contexto, o seu próprio focus, o seu próprio tooling.
É exatamente isto que o Agent Teams traz ao AgentsRoom. Pões nodes num canvas infinito (baseado em React Flow, o mesmo motor que n8n, Make, Retool e Pipedream), cada node é um agente Claude Code, Codex, OpenCode, Gemini CLI ou Aider atribuído a um papel específico, e ligas-os. Lança a equipa num ticket do teu backlog, ou anexa-a a qualquer novo spawn de agente. AgentsRoom orquestra a cadeia: spawn do primeiro agente, espera do handoff, resume do trabalho, spawn do agente seguinte com esse resume como contexto de entrada, repete até a equipa atingir o node final.
Outras ferramentas tentam fazer isto com um super-agente único e prompts engenhosos. Tentámos, não funciona para além de três passos. Os papéis derivam, o contexto perde-se, o agente esquece-se do que tinha de verificar. Agent Teams trata os agentes como verdadeiros companheiros de equipa: cada um recebe uma sessão limpa, um system prompt focado, um payload de handoff estruturado, e um scratchpad partilhado para falar com os outros. Este é o workflow de equipa dev IA que tu queres mesmo.
Editor AgentsRoom Teams: põe nodes para cada papel, liga-os, adiciona condições, guarda a equipa, lança em qualquer ticket.
Orquestração multi-agente que escala a sério
Cada node no canvas é um agente. Escolhes o seu papel (Fullstack, Frontend, Backend, QA, Security, DevOps, PM, Architect, Mobile, Marketing, Git, SEO, Localization, ou qualquer papel custom que tenhas criado), o seu modelo (Opus, Sonnet, Haiku, GPT-5, o3, Gemini Pro, etc.), o seu modo de handoff (auto via Stop hook, ou manual via botão) e algumas linhas de instruções específicas do passo. É só isso. Sem cerimónia de prompt engineering, sem ficheiro YAML para escrever.
Os edges ligam os nodes. Um edge simples significa: quando o primeiro agente termina o seu passo, passa ao seguinte. Um edge condicional carrega um check de flag, por exemplo qaPassed equals true. O agente QA põe essa flag no seu payload de handoff, o runner escolhe o edge correspondente. É assim que constróis loops de feedback: QA termina, qaPassed equals false, o edge devolve ao Dev com as pistas de teste e os riscos. Dev corrige, faz handoff outra vez. Loop até o QA passar ou até o guard de max-cycles disparar.
A comunicação inter-agente é robusta por design. AgentsRoom inclui um servidor MCP dedicado (agentsroom-team) que dá a cada agente do run um conjunto de tools: ler o contexto da equipa, ler o scratchpad NOTES.md partilhado, postar uma nota para os colegas, enviar uma pergunta a outro papel, ler a inbox, ler a timeline, ler o diff git contra a baseline do run, e completar o passo com um payload estruturado. Estas tools são reinjetadas na sessão Claude em cada turn, por isso sobrevivem à compactação de contexto. Mesmo depois de um /compact ou /clear, o agente continua a ver as suas tools de equipa.
Para além disso, um hook UserPromptSubmit lembra ao agente quaisquer notas novas dos colegas antes de cada mensagem do utilizador. Um ficheiro NOTES.md no workspace é append-only e sobrevive a crashes, reinícios e reboots de Mac. Um schema de payload de handoff validado do lado do servidor impede que os agentes façam handoffs vazios ou de lixo. Esta é a parte que a maioria das demos multi-agente saltam em silêncio, e a razão pela qual a maioria desmorona-se no cycle 3.
Tudo o que precisas para gerir uma equipa de engenharia IA
Workflow visual, handoff real, loops de feedback reais, comunicação inter-agente real. Construído para entregares uma feature num ping de Slack em vez de cinquenta.
Canvas de workflow visual
Canvas zoomável infinito impulsionado por React Flow, o mesmo motor por trás de n8n, Retool, Pipedream e Make. Põe nodes, liga-os, guarda a equipa. Sem código, sem YAML.
14 papéis de agente integrados
Fullstack, Frontend, Backend, DevOps, QA, Security, PM, Architect, Mobile, Marketing, Git Expert, SEO, i18n. Mais qualquer papel custom que já tenhas guardado no teu projeto.
Modelo e prompt por node
Cada node escolhe o seu provider, o seu modelo e as suas instruções de passo. Usa Opus para Architect, Haiku para QA, Codex para o backend pesado, Gemini para o frontend barato. Mix and match.
Handoff automático
Quando um agente chama team_complete_step, AgentsRoom constrói o payload de handoff (resumo de feature, ficheiros alterados, riscos, pistas de teste, flags) e spawna o node seguinte com esse payload como contexto inicial.
Opção de handoff manual
Preferes validar cada passo? Põe o node em modo manual. O agente espera, tu carregas em 'Hand off' quando estiveres satisfeito com o resultado. O melhor de dois mundos.
Edges condicionais
Cada edge pode carregar um check de flag (por exemplo qaPassed equals true). Constrói branches: se QA passa, vai ao PM, senão volta em loop ao Dev. Lógica de workflow real, sem scripting.
Loops de feedback
Dev para QA para Dev para QA. Quando o QA devolve o ticket, o agente Dev original é reutilizado com memória completa do cycle anterior, por isso corrige a regressão a sério em vez de começar do zero.
Guard de max-cycles
Tecto configurável (3 por defeito). Evita loops infinitos QA-rejeita-Dev. Quando o tecto é atingido, o run pausa em awaiting-finalization e tu decides o que fazer.
Scratchpad NOTES.md partilhado
Cada agente do run lê e escreve num ficheiro markdown do workspace. Sobrevive à compactação, ao crash, ao reinício. A fonte única de verdade para o raciocínio da equipa.
Inbox papel-a-papel
Precisas que o QA faça uma pergunta ao Architect a meio do run? team_ask posta uma mensagem na inbox do papel. O agente seguinte desse papel lê-a e responde. Chat real entre agentes.
Comm inter-agente via MCP
Todas as tools de equipa são expostas via servidor MCP. As tools sobrevivem à compactação de contexto Claude (Anthropic reenvia-as em cada turn). Resistentes a /clear, /compact e loops longos.
Resumo de handoff alimentado por Haiku
Se um agente não escreve o seu próprio resumo de feature, uma pequena chamada Haiku gera um a partir do diff git. Barato, rápido, e o agente seguinte aterra sempre com contexto.
Propagação Browser MCP
Um node de equipa com verifyInBrowser muda o seu agente para modo browser-access automaticamente. O node QA aterra com todas as tools de browser (navigate, click, type, screenshot, get logs).
Agentes efémeros por run
Cada run de equipa spawna agentes frescos e destrói-os ao dismiss. A tua lista de agentes do projeto mantém-se limpa. A equipa é o workflow, os agentes são o runtime.
Equipas globais e de projeto
Guarda equipas reutilizáveis na tua biblioteca global (~/.agentsroom/teams) ou prende-as a um projeto específico (commitadas com a room). Mesmo editor, scope diferente.
Templates de equipa incluídos
Três templates iniciais vêm com a app: Dev para QA, Dev para QA com loop de feedback, e Dev para Security para QA. Duplica, edita, lança. Começa em 30 segundos.
UI da timeline do run
Cada handoff aparece como um cartão na timeline do run: que papel acabou de terminar, o que diz o resumo, que ficheiros mudaram, que flags foram postas. Auditável, replayable.
Lança em qualquer ticket de backlog
Põe um ticket numa equipa e a cadeia arranca nesse ticket. O primeiro agente lê o título e o body do ticket, o resto da equipa pega a partir daí.
14 papéis especializados, prontos a serem ligados
Cada papel tem o seu próprio system prompt, áreas de focus e tarefas exemplo. Mistura-os no canvas. Adiciona os teus próprios papéis custom a qualquer momento.
Porque é que uma verdadeira equipa vence um super-agente
A orquestração multi-agente soa a buzzword. Aqui está a diferença prática, numa feature que entregarias mesmo.
Cenário: adicionar um flow de checkout Stripe a um site de e-commerce
Super-agente solo
- • Lê o ticket. Escreve 600 linhas entre a API, o formulário React, o webhook, a migração e os testes.
- • Esquece a idempotency key no webhook. Esquece de testar o caminho de falha. Esquece a variável de ambiente de staging.
- • Diz 'Done'. Passas duas horas a caçar bugs em produção.
Agent Team (Dev para Security para QA)
- • Agente Fullstack entrega a implementação, commit, faz handoff com um resumo e uma lista de riscos a sinalizar a alteração de auth.
- • Agente Security lê o diff, audita a verificação de assinatura do webhook, escreve pistas de teste para o QA no payload de handoff.
- • Agente QA executa as pistas de teste no navegador integrado, encontra um bug de idempotência, põe qaPassed equals false, devolve o ticket ao Dev com a repro exata.
- • Dev corrige, faz handoff outra vez. QA passa. O PM finaliza. O run vai para done.
Mesmo ticket, mesmos modelos, mesmo projeto. Forma de trabalho diferente. A abordagem de equipa apanha o que o agente solo perde, porque cada papel tem um brief focado e um handoff estruturado.
Como funciona um run de equipa
Abre o separador Teams
Na vista do projeto, o separador Teams lista três templates iniciais (Dev para QA, Dev para QA com loop de feedback, Dev para Security para QA) mais qualquer equipa que já tenhas guardado. Duplica um template ou carrega em 'Nova equipa'.
Constrói o workflow no canvas
Põe nodes de agente no canvas React Flow. Para cada node, escolhe o papel (Fullstack, QA, Security, PM, etc.), o provider, o modelo, e algumas linhas de instruções de passo. Liga-os com edges. Adiciona condições nos edges se precisares de branching.
Dev → QA → PMDefine o modo de handoff por node
Handoff auto: o agente chama team_complete_step quando o seu trabalho está feito, o runner toma conta. Handoff manual: o agente espera que carregues em 'Hand off'. Mistura ambos conforme necessário.
Lança a equipa
A partir de um ticket de backlog, carrega em 'Run with team'. A partir de um slot de agente vazio, carrega em 'Create as team'. O primeiro node spawna como agente efémero no workspace do projeto.
Vê o handoff acontecer
Quando o agente N termina, AgentsRoom constrói o payload de handoff (resumo de feature via agente ou via Haiku, diff git, riscos, pistas de teste, flags), anexa uma nota ao NOTES.md, escolhe o edge de saída certo com base nas flags, e spawna o agente N+1 com esse payload como contexto de entrada.
Loop, fim, finalização
Os loops de feedback re-entram no agente original (memória completa preservada). O node final dispara awaiting-finalization. Carregas em 'Finish run'. Dismiss do banner para destruir os agentes e libertar os PTYs.
Comunicação inter-agente que sobrevive a tudo
O detalhe que a maioria das demos multi-agente saltam. Aqui está o que faz com que o Agent Teams aguente em runs longos e muitos cycles.
Os agentes Claude Code têm uma janela de contexto e compactam-na. O erro clássico dos sistemas multi-agente é pôr a coordenação de equipa só no system prompt. Depois de dois cycles de /compact, o agente não faz ideia de que está numa equipa. AgentsRoom não faz isso.
Toda a coordenação de equipa vive em três sítios que sobrevivem à compactação. Primeiro, um servidor MCP (agentsroom-team) expõe tools (team_get_context, team_read_notes, team_post_note, team_read_inbox, team_ask, team_read_timeline, team_read_diff, team_complete_step). As tools MCP são reenviadas pela CLI ao Claude em cada turn, por isso são imunes à compressão de contexto.
Segundo, um hook UserPromptSubmit corre antes de cada mensagem do utilizador e prepende um pequeno lembrete se houver notas novas ou mensagens novas na inbox desse papel. Barato quando não há nada, decisivo quando há.
Terceiro, NOTES.md e state.json vivem em disco no workspace. O agente pode relê-los a qualquer momento com um Read simples ou com team_read_notes. Sobrevivem a crashes, reinícios, /clear, /compact e reboots de Mac. O system prompt nunca é a fonte de verdade, o disco e as tools MCP são.
O que as pessoas constroem com Agent Teams
Pipeline Dev para QA
O clássico. Fullstack entrega a feature. QA valida-a no navegador integrado, executa as pistas de teste, assina. Equipa de dois nodes, corre em cada ticket do backlog.
Dev para QA com loop de feedback
Como acima, mas com um edge condicional: qaPassed equals false devolve o ticket ao Dev com as pistas de teste. Máx 3 cycles. Apanha regressões antes que cheguem a um reviewer humano.
Dev para Security para QA
Para features que tocam em auth, pagamentos ou PII. Agente Security faz review do diff, sinaliza riscos, escreve pistas de teste para o QA. Usado por equipas que entregam fintech, healthtech e SaaS B2B.
PM para Architect para Dev
Workflow spec-first. O agente PM transforma o ticket numa spec estruturada. O Architect escolhe a abordagem. O Dev implementa. Três papéis, separação limpa, decisões rastreáveis.
Fan-out Frontend, Backend, DevOps
Divisão sequencial para features full-stack. Frontend entrega a UI. Backend entrega a API. DevOps adiciona a config de infra. Cada papel trabalha na sua área, faz handoff com um diff limpo.
Marketing para SEO para i18n
Sim, AgentsRoom Teams não é só para código. Marketing escreve o copy da landing. SEO injeta os keywords. Localization traduz para 14 línguas. Uma equipa, um ticket, um ship.
Como se compara com outras abordagens multi-agente
A orquestração multi-agente é um buzzword saturado. Aqui está o que entrega mesmo, e onde encaixa o AgentsRoom Teams.
Anthropic Subagents (tool Task, .claude/agents) deixam uma sessão Claude única delegar a agentes helper especializados. Ótimo para delegação inline, mas a sessão pai continua a ser o coordenador e um contexto único. AgentsRoom Teams está um nível acima: cada node de equipa é uma sessão Claude top-level separada com a sua própria janela, o seu próprio estado, o seu próprio scrollback. CrewAI, AutoGen e LangGraph são frameworks Python excelentes para flows multi-agente, mas vivem fora do teu IDE e não correm CLIs reais Claude Code, Codex ou Gemini end-to-end no teu repo local. n8n, Make, Pipedream e Retool entregam o mesmo tipo de editor canvas que usamos, mas são plataformas de automação generalistas, não construídas para agentes IA de código. AgentsRoom Teams é o editor de workflow multi-agente estilo canvas, mas ligado especificamente aos teus agentes CLI, ao teu projeto, ao teu git, aos teus terminais e ao teu navegador.
Se constróis sistemas agênticos em Python, continua com CrewAI ou LangGraph para pipelines de produção. Se entregas código com Claude Code, Codex CLI, OpenCode, Gemini CLI ou Aider, Agent Teams é o workflow de equipa que corre onde tu codas mesmo.
FAQ
Em que é que isto é diferente dos subagents do Claude Code (a tool Task, .claude/agents)?
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.
Isto só funciona com Claude Code?
Funciona com todos os providers suportados pelo AgentsRoom (Claude Code, Codex CLI, OpenCode, Gemini CLI, Aider). 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.
O que é um payload de handoff?
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.
Os agentes podem mesmo ir e voltar (Dev para QA para Dev)?
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.
O que acontece se o QA continuar a rejeitar o Dev para sempre?
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.
Todos os agentes da equipa partilham o mesmo workspace git?
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.
Isto requer uma subscrição extra?
Não. Teams faz parte do AgentsRoom. Trazes as tuas próprias keys de provider (Claude, Codex, OpenCode, Gemini, Aider) 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.
Onde é que as equipas são guardadas? São commitadas no git?
As equipas com scope de projeto vivem com a room, sincronizadas para a cloud e em cache em {project}/.agentsroom/teams-cache.json (gitignored). As equipas globais vivem em ~/.agentsroom/teams/{teamId}.json na tua máquina, um ficheiro por equipa. Tu decides que scope encaixa com cada workflow.
E se um agente crashar ou a app reiniciar a meio do run?
O estado do run está persistido em disco em {workspace}/.agentsroom/team-runs/{runId}/ (state.json, NOTES.md, inbox/, timeline.jsonl). NOTES.md é append-only, cada escrita de estado é atómica. Os agentes podem reler tudo a qualquer momento com team_read_notes ou team_get_context. A camada de orquestração está a ser endurecida para fazer replay completo de um run interrompido ao reiniciar a app, mas a história on-disk já é crash-safe.
Posso correr várias equipas em paralelo em tickets diferentes?
Sim. Cada run de equipa é independente e identificado pelo seu runId. Podes ter uma equipa Dev para QA a correr no ticket A, uma equipa Dev para Security para QA no ticket B e uma equipa PM para Architect para Dev no ticket C, todas ao vivo no mesmo projeto. Dentro de um run único, a execução é sequencial (um node ativo de cada vez) por previsibilidade.
Constrói a tua equipa dev IA dos sonhos
Três templates vêm com a app. Abre AgentsRoom, põe nodes, desenha edges, lança em qualquer ticket. A tua equipa de engenharia IA está a um clique.
App complementar: acompanhe seus agentes em qualquer lugar
Compatível com Claude, Codex, OpenCode, Gemini CLI e Aider
Envie bugs e pedidos direto para o seu backlog público.