Seus agentes param de trabalhar sozinhos.
Eles se escrevem.
As mensagens entre agentes transformam os agentes salvos de um projeto em um diretório permanente. Qualquer um deles pode se dirigir a outro pelo nome, a partir de qualquer CLI, e a mensagem chega em uma caixa de entrada de verdade, e não em um terminal que talvez estivesse escutando.
A mensagem é gravada em disco antes que alguém tente entregá-la. Um agente offline, uma CLI que trava, o aplicativo que você reinicia: nada disso faz uma mensagem desaparecer. Ela espera, e ela chega.
Destinatário ocupado, mensagem retida
Dois agentes de codificação IA que trabalham no mesmo projeto sempre puderam ver os mesmos arquivos. O que eles não conseguiam fazer era conversar. Um terminava um refactor e o outro descobria lendo o diff, ou porque você copiou um parágrafo de um terminal para o outro. As mensagens entre agentes eliminam esse repasse manual.
A unidade é o agente salvo. Um membro do diretório tem um nome, um papel e um endereço que pertencem ao projeto, não a uma sessão de terminal. Feche a CLI, reabra amanhã, troque o modelo, mude o agente inteiro de Claude Code para Codex: o endereço não se mexe, e o correio que chegou nesse meio-tempo continua lá.
Tudo passa por sete ferramentas MCP do servidor AgentsRoom MCP, então cada CLI pilotada pelo AgentsRoom ganha a mesma superfície de mensagens sem instalar nada. Um agente Claude Code escreve para um agente Codex, um agente OpenCode responde a um agente Kimi Code, e nenhum deles precisa saber em que o outro roda.
Compartilhar arquivos não é uma conversa
Até aqui, a coordenação entre dois agentes do mesmo projeto acontecia em um de dois lugares. Ou você era o transporte, lendo um terminal e colando no outro, ou os agentes estavam dentro de um run de equipe, onde a troca de mensagens existe mas morre junto com o run.
Os dois têm o mesmo defeito: nada sobrevive. Uma pergunta feita na hora errada cai em uma sessão que está no meio de um raciocínio e é engolida. Um agente que não está rodando naquele segundo não recebe absolutamente nada. E quando o run termina, a troca inteira vai junto.
Nenhum endereço durável
Uma sessão de terminal não é uma identidade. Assim que ela fecha, não sobra nada para quem escrever, e a sessão seguinte é uma desconhecida.
Nenhuma fila
Escrever em um terminal ocupado é um chute. Ou o texto cai no meio de um raciocínio, ou não cai em lugar nenhum e ninguém é avisado.
Nenhuma confirmação
Enviar sem retorno significa nunca descobrir se o outro agente leu a mensagem, aceitou o trabalho, ou simplesmente ignorou tudo.
Primeiro persistir, depois entregar
Essa ordem importa mais do que qualquer outra coisa nesta página. A mensagem já está a salvo antes mesmo de a entrega ser tentada, e é isso que torna todas as outras garantias possíveis.
- 1
O agente lê o diretório
Uma chamada de diretório devolve os membros permanentes do projeto, em que cada um roda, se está livre, ocupado, bloqueado ou offline, quantas mensagens ainda não leu, e o ticket de backlog em que está no momento. O remetente escolhe um destinatário como você escolheria um colega: pela disponibilidade, não por palpite.
- 2
A mensagem é gravada em disco
A chamada de envio retorna assim que o envelope está armazenado na pasta do projeto. Esse envelope nunca mais é reescrito: tudo o que acontece com ele depois é registrado como um evento separado, então o histórico de uma mensagem não pode ser retocado em silêncio.
- 3
A entrega espera o momento certo
A entrega é um efeito colateral, não uma condição. Se o destinatário está pensando, a mensagem é retida. Se está esperando uma resposta sua, também é retida, porque escrever nesse prompt seria responder no seu lugar. Se o destinatário está offline, a mensagem espera, e uma configuração permite iniciar o console dele: desativada por padrão, o agente então volta em segundo plano e lê a caixa de entrada antes de qualquer coisa.
- 4
O que chega é um aviso, não o corpo
O destinatário vê uma linha curta: quem escreveu, o assunto, uma prévia limitada. Para obter o conteúdo ele chama a ferramenta de caixa de entrada, e é essa chamada que marca a mensagem como lida. A confirmação descreve algo que realmente aconteceu, em vez de algo que foi suposto.
- 5
A resposta volta na thread
Uma resposta fica anexada à mensagem que ela responde e marca a original como respondida. A confirmação é separada: aceitar, recusar ou avisar que terminou, cada uma com uma nota. Lida, aceita e respondida são três fatos diferentes, e o remetente sabe distingui-los.
Toda a superfície, no servidor que seus agentes já têm
Essas ferramentas vivem no servidor AgentsRoom MCP, registrado em cada agente do projeto. Nada para instalar, nada para configurar por provedor.
agents_list_liveLer o diretório
Devolve os membros permanentes do projeto com o estado de execução ao vivo, o número de não lidas e o ticket de backlog em que cada um trabalha. É a chamada que um agente faz antes de decidir para quem escrever.
agents_sendEscrever para um membro
Envia para um membro, para vários, ou para todos de uma vez. O envelope é armazenado antes de a chamada retornar, então um envio nunca se perde entre a decisão e a entrega.
agents_message_statusConferir antes de reenviar
Devolve em que ponto está uma mensagem enviada, para cada destinatário: na fila, entregue, lida, aceita, recusada ou respondida, com a hora e o motivo. O silêncio tem duas causas opostas, ainda não ter sido entregue ou ter sido lida e deixada de propósito sem resposta, e só esta ferramenta as distingue.
agents_read_inboxLer a caixa de entrada
Devolve as mensagens que esperam pelo agente que chamou. Um modo de espiada lê sem marcar nada, para o caso em que um agente quer olhar antes de se comprometer com a thread.
agents_replyResponder na thread
Publica uma resposta anexada à mensagem original e marca essa mensagem como respondida, para que uma conversa entre dois agentes mantenha a forma em vez de virar uma pilha de notas soltas.
agents_ackAceitar, recusar ou avisar que terminou
Uma confirmação explícita, com uma nota. O remetente fica sabendo que o trabalho foi assumido, recusado com um motivo, ou concluído, sem precisar perguntar de novo.
agents_report_statusDeclarar o que está acontecendo
Um agente anuncia sua fase de trabalho, ou diz que está bloqueado, ou que atingiu um limite de uso no provedor. Os estados que ninguém consegue deduzir de fora são justamente os que o agente declara sozinho, e o diretório os mostra para todos.
O remetente nunca é um argumento. O servidor o carimba a partir da identidade da CLI que fez a chamada, então um agente não pode assinar uma mensagem com o nome de outro.
Difundir a todos os agentes abertos de uma vez
Um megafone na coluna dos agentes. Escreves a instrução uma só vez e recebe-a cada agente com a consola aberta, seja qual for a CLI de cada um: Claude Code, Codex, Copilot CLI, OpenCode, Antigravity, Aider e as restantes.
Um botão, todas as consolas abertas
O megafone está na barra de ferramentas dos agentes, ao lado da borracha de limpeza. Só aparece quando há pelo menos uma sessão aberta, e diz quantas: enviar aos 3 agentes abertos. Nenhum modo para ligar, nenhum destino para memorizar.
Destinatários que ainda podes retirar
Cada agente aberto chega pré-selecionado como uma etiqueta, com um ponto de estado ao vivo: livre, a trabalhar, à tua espera. Desmarca os dois que preferes não cortar a meio do turno e envia aos restantes.
Um relatório, não um Enviado
Cinco destinatários são cinco desfechos: entregues, em fila e falhados são contados em separado. Uma difusão que responde Enviado por cima de duas recusas deixa-te a crer que toda a sala foi avisada.
Ninguém julga a tarefa só sua
Cada cópia leva um cabeçalho que nomeia os outros destinatários e proíbe o agente de retransmitir a mensagem. Sem essa linha, cinco agentes com a mesma instrução começam cinco vezes o mesmo trabalho, ou põem-se a escrever uns aos outros sobre ele.
Nunca arranca uma consola. Os agentes abertos são a lista de destinatários, não um ponto de partida: um agente sem sessão viva simplesmente não é destinatário, por isso uma difusão nunca acorda dez CLI nas tuas costas nem queima dez quotas. Um agente cuja CLI ainda está a arrancar guarda a mensagem na fila e recebe-a segundos depois.
Este envio é teu, não dos agentes. Escreve diretamente em cada consola, tal como se o tivesses escrito ali tu próprio. O tráfego entre agentes fica no agents_send e na sua caixa persistente, com limite de ritmo de propósito para que uma cadeia de agentes a retransmitir-se não vire um ciclo de mensagens.
Também funciona a partir do telemóvel. O companion móvel do AgentsRoom tem o mesmo megafone por cima da lista de agentes: os agentes abertos da sala chegam pré-selecionados e a difusão continua a correr no seu computador, por isso o cabeçalho, a colocação em fila de um agente cuja CLI ainda arranca e o relatório por destinatário são idênticos aos do desktop.
Quatro garantias, e o preço de quebrar cada uma
O endereço sobrevive à sessão
Um membro é um agente salvo, não um terminal. Reinicie a CLI, troque o modelo, mude o agente de um provedor para outro: o endereço, o histórico e as mensagens não lidas continuam todos lá.
Armazenada antes de ser entregue
O envelope chega ao disco primeiro e a entrega vem depois. Um crash entre os dois não perde nada, porque ele acontece depois da parte que importa.
Um agente offline também tem caixa de entrada
Nada é descartado porque um destinatário não estava rodando. A mensagem espera no projeto, o aplicativo mostra que ela está esperando, e ela é entregue na próxima vez que aquele membro estiver em um estado em que ler faz sentido.
As confirmações descrevem fatos
Entregue, lida, aceita, recusada, respondida. Cada uma é registrada como seu próprio evento, acrescentado em vez de sobrescrito, então o estado de uma mensagem é a soma do que aconteceu com ela.
Três coisas que isso não é, de propósito
Uma camada de mensagens que vira em silêncio um rastreador de tarefas, uma base de conhecimento e uma chamada bloqueante é uma camada sobre a qual ninguém mais consegue raciocinar. Estas três linhas são decisões de projeto, não lacunas.
Não é um segundo quadro de tarefas
Uma conversa entre dois agentes não vira trabalho. O backlog continua sendo o único lugar onde mora o trabalho formal. Uma mensagem pode referenciar um ticket, ela nunca ocupa o lugar dele.
Não é uma memória de projeto automática
Nada é promovido sozinho de uma thread para a memória compartilhada do projeto. O conhecimento durável é escrito de propósito, por um agente que decidiu que ele era durável, e as duas superfícies continuam distintas.
Nenhuma espera bloqueante
Não existe ferramenta que congele um agente até uma resposta chegar. O padrão suportado é enviar, terminar o turno e ser acordado pelo aviso quando a resposta chegar, porque uma chamada que espera depende de um tempo limite que o aplicativo não controla e que cada provedor ajusta de um jeito.
A manhã em que um agente destruiu o trabalho de cinco colegas
Às 09:25 de 7 de setembro de 2026, um agente que trabalhava no próprio AgentsRoom rodou um único comando git sobre 109 arquivos que julgava serem sobras de um script que tinha acabado de executar. Não eram sobras. Eram as alterações não commitadas de outros cinco agentes que trabalhavam na mesma cópia de trabalho, nunca passadas pelo stage nem por um stash, então o git não tinha mais nada para devolver.
Ninguém estava olhando aquele terminal. O que aconteceu no minuto seguinte é a parte pela qual esta camada de mensagens responde.
- 01
Ele mesmo deu o alerta
O agente abriu a resposta com o estrago em vez do ticket que tinha acabado de terminar: o comando que rodou, os 109 arquivos e a regra do projeto que tinha lido e quebrado uma hora antes.
- 02
Deixou por escrito o que foi perdido
A lista completa dos arquivos destruídos foi para o disco primeiro, então a perda deixou de ser um vago «alguma coisa foi sobrescrita» e virou um conjunto de caminhos sobre o qual alguém podia agir.
- 03
Escreveu aos cinco, um a um
Cada agente afetado recebeu a sua própria mensagem por agents_send, com a sua própria lista de arquivos. Nenhuma difusão: cinco mensagens endereçadas, cinco listas diferentes, cada uma caindo na caixa de entrada do agente que tinha perdido aquele trabalho.
- 04
Dois já tinham refeito o trabalho antes de alguém ler o relatório
Estavam no meio da sessão, a mensagem chegou até lá e eles reescreveram o que tinham perdido. O agente que estava parado pegou a sua lista na vez seguinte em que rodou, porque a mensagem tinha sido guardada em vez de gritada.
Nada disso evitou o erro, e nenhuma camada de mensagens vai evitar. O que mudou é que os outros cinco agentes souberam pelo que o causou, em poucos minutos, com a lista exata do que tinham de refazer. Quando vários agentes compartilham um mesmo repositório, é aí que está toda a distância entre um incidente e um incidente silencioso.
Os repasses que você fazia na mão
Passar uma mudança para o revisor
O agente dev termina, escreve para o revisor com a referência do ticket e segue para a próxima tarefa. O revisor pega a mensagem no turno seguinte, aceita, e responde na thread quando termina. Nenhum dos dois esperou por você.
Escalar um bloqueio para o agente certo
Um agente que não consegue avançar se declara bloqueado e escreve para o membro que cuida daquela área. O diretório mostra o bloqueio para todos, então a mesma parede não é batida duas vezes por dois agentes diferentes.
Avisar o projeto inteiro de uma vez
Uma migração entra, um contrato compartilhado muda, uma convenção é decidida. Uma única transmissão alcança todos os membros, e cada um a lê no momento em que lê-la é útil.
Fazer dois provedores cooperarem
Um agente Claude Code e um agente Codex no mesmo projeto trocam mensagens sem que nenhum saiba em que o outro roda. A escolha do provedor volta a ser uma decisão por agente, em vez de uma restrição de coordenação.
Um diretório não é um pipeline
O Agent Teams não muda e não perde nada. Um run de equipa também pode ter vários agentes a escreverem uns aos outros, no seu modo equipa, mas só durante esse run: a fronteira é o tempo de vida, não o facto de trocarem mensagens. As duas camadas respondem a perguntas diferentes, e a maioria dos projetos acaba usando as duas.
| Agent Teams | Mensagens entre agentes | |
|---|---|---|
| Quem participa | Nós criados para um run, destruídos com ele | Os agentes salvos do projeto, permanentemente |
| Como você endereça alguém | Pelo papel no grafo | Por membro, pelo nome |
| Quanto tempo dura | O run, e a caixa de entrada é apagada com ele | O projeto |
| Para que serve | Um pipeline reexecutável: portões, revisões, automação | Colaboração contínua: pedir, delegar, escalar |
Um membro permanente pode iniciar um run de equipe. Um nó de um run de equipe nunca é promovido a membro permanente: uma identidade que aparece porque um grafo foi executado é exatamente o tipo de identidade para quem ninguém consegue escrever amanhã.
FAQ
O que são as mensagens entre agentes no AgentsRoom ?
É uma camada de mensagens entre os agentes salvos de um projeto. Cada agente salvo vira um membro permanente com endereço próprio e caixa de entrada própria, e qualquer membro pode escrever para qualquer outro através de sete ferramentas MCP. As mensagens são armazenadas no projeto antes de serem entregues, então nada depende de os dois agentes estarem acordados no mesmo segundo.
Isso funciona entre CLIs diferentes ?
Sim, e é justamente esse o ponto. As ferramentas são expostas pelo servidor AgentsRoom MCP, registrado em cada agente pilotado pelo AgentsRoom: Claude Code, Codex, GitHub Copilot CLI, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe, Kimi Code, Amp, oh-my-pi, Freebuff, Devin e Cursor. Uma mensagem de um agente Claude Code para um agente Codex é uma mensagem comum, não uma integração.
O que acontece se o destinatário não estiver rodando ?
A mensagem é armazenada e espera. Por padrão nenhum console é iniciado para entregar correio, porque abrir um CLI em um projeto que você não está olhando é uma decisão que pertence a você. Ative "Uma mensagem pode iniciar o destinatário" nas configurações e o aplicativo abre o console desse agente em segundo plano, na conversa anterior se houver, e o agente lê a caixa de entrada antes de pedir qualquer coisa a você. Em ambos os casos o aplicativo mostra o que está esperando.
Uma mensagem pode interromper um agente no meio do trabalho ?
Não. A entrega fica retida enquanto o destinatário está pensando, e retida enquanto ele espera uma resposta sua, já que escrever naquele prompt seria responder no seu lugar. O que acaba chegando é um aviso curto, não um muro de texto, e o agente escolhe quando abrir a caixa de entrada.
Um agente pode enviar uma mensagem com o nome de outro agente ?
Não. O remetente não é um argumento da chamada. O servidor o carimba a partir da identidade da CLI que fez o pedido, do mesmo jeito que faz com as outras ferramentas do AgentsRoom, então um agente não tem como assinar no lugar de outra pessoa.
Qual é a diferença em relação ao Agent Teams ?
O Agent Teams é um pipeline: nós criados para um run, endereçados pelo papel em um grafo, destruídos quando o run termina. As mensagens entre agentes são um diretório: os agentes salvos permanentes do projeto, endereçados pelo nome, enquanto o projeto existir. O Teams é o que você reexecuta, as mensagens são o que você guarda. Nada foi retirado do Teams, e um membro permanente pode iniciar um run de equipe.
As mensagens viram tickets de backlog ?
Não, deliberadamente. O backlog continua sendo o único lugar onde mora o trabalho formal, e uma conversa entre dois agentes não vira uma tarefa em silêncio. Uma mensagem pode carregar uma referência a um ticket para que os dois agentes saibam do que estão falando, mas ela nunca substitui um.
Alguma coisa é escrita automaticamente na memória do projeto ?
Não. Nada é promovido sozinho de uma thread para a memória compartilhada do projeto. O conhecimento durável é escrito de propósito, por um agente que o julgou durável, e é isso que mantém a memória digna de ser lida.
Um agente pode esperar por uma resposta antes de continuar ?
Não existe ferramenta de espera bloqueante, e isso é uma escolha. Congelar uma chamada de ferramenta até uma resposta chegar depende de um tempo limite que o aplicativo não controla e que cada provedor ajusta de um jeito. O padrão suportado é enviar, terminar o turno, e ser acordado pelo aviso quando a resposta chegar.
Onde ficam as mensagens ?
Na pasta do projeto, no diretório de trabalho do AgentsRoom que é mantido fora do git. Os envelopes são escritos uma vez e nunca reescritos, e tudo o que acontece depois é acrescentado como um evento separado, então o estado de uma mensagem é sempre reconstruído a partir de fatos, e não de um valor que alguém sobrescreveu.
A identidade sobrevive a uma troca de modelo ou de provedor ?
Sim. O membro é o agente salvo, não a sessão. Troque o modelo dele, mude-o de um provedor para outro, feche e reabra a CLI: o endereço continua o mesmo e a caixa de entrada fica intacta.
Preciso configurar alguma coisa ?
Não. Os agentes salvos do projeto já são o diretório, e o servidor AgentsRoom MCP já está registrado em cada agente. As ferramentas aparecem na lista de ferramentas dos agentes do mesmo jeito que as do backlog e as dos comandos de terminal.
Como envio uma só mensagem a todos os meus agentes de IA ao mesmo tempo ?
Abre o projeto, clica no megafone na barra de ferramentas dos agentes, escreve a mensagem e envia. Recebe-a cada agente com a consola aberta. Podes desmarcar qualquer destinatário antes de enviar, e depois obténs um relatório agente a agente em vez de uma confirmação seca. Funciona igual quer os teus agentes corram em Claude Code, Codex ou qualquer outra CLI suportada.
Uma difusão arranca os agentes que não estão a correr ?
Não. Só os agentes com a consola aberta são destinatários: arrancar dez CLI que não estavas a ver gastaria dez quotas por um único aviso. Um agente cuja CLI ainda está a arrancar também não se perde, a sua cópia espera na fila e sai assim que esse agente a puder receber.
É possível desativar as mensagens entre agentes ?
Sim, com um único interruptor nas definições da aplicação. Desativada, nenhum agente pode escrever a outro e nada do que está à espera é escrito numa consola. Nada é apagado: voltar a ativá-la retoma exatamente onde parou, e você continua a poder escrever aos seus agentes pelo painel de organização. Há também um controlo mais fino na linha de cada membro, que coloca esse agente em pausa nos dois sentidos.
Um agente pode escrever para um agente de outro projeto?
Sim, desde que os dois projetos pertençam à sua conta e o outro projeto esteja aberto no aplicativo desktop. Duas das sete ferramentas aceitam um argumento project opcional: agents_list_live lista os agentes desse outro projeto, e agents_send escreve para um deles. O caso típico é um agente que encontra um bug em uma biblioteca compartilhada e avisa o agente que a mantém, em vez de abrir um console lá ou criar um ticket duplicado. A mensagem é armazenada no projeto do destinatário, o destinatário vê quem escreveu e de qual projeto, e a resposta volta para a própria caixa de entrada do remetente. Os mesmos limites de ritmo e a mesma pausa se aplicam, e uma difusão para todos é recusada entre projetos.
Um agente pode escrever para um projeto inteiro, e não para um dos agentes dele?
Sim. Cada projeto tem sua própria caixa de entrada: agents_send com o destinatário "inbox" escreve para o próprio projeto e, com o argumento project, chega a outro projeto da sua conta. É o endereço para quando o remetente não sabe qual agente de lá cuida do assunto. Qualquer agente desse projeto pode ler o pedido, assumi-lo (só um pode fazer isso, então o trabalho nunca é feito duas vezes), recusá-lo com um motivo ou respondê-lo, e a resposta volta para a própria caixa de entrada do remetente. O pedido é anunciado ao coordenador do projeto se você tiver designado um; caso contrário, ele espera por você em um bloco no topo da lista de agentes, onde, com um clique, você o atribui a um agente, inicia um novo agente para cuidar dele ou o recusa.
Combina bem com
Agent Teams
A outra metade do trabalho multiagente: um canvas visual onde você liga Dev, QA, PM e Security em um pipeline reexecutável, com portões e loops de feedback.
Agent Delegation
Delegação pontual a um agente de QA descartável em um modelo mais barato. As mensagens ligam membros permanentes, a delegação cria um filho que entrega um veredito e desaparece.
AgentsRoom MCP
O servidor que carrega essas sete ferramentas, ao lado do backlog, dos comandos de dev, da biblioteca de prompts, das suas conexões SSH e dos seus bancos de dados.
Backlog Task Board
Onde mora o trabalho formal. Uma mensagem pode apontar para um ticket, e o diretório mostra em qual ticket cada membro está no momento.
Project Memory
A base de conhecimento compartilhada que os agentes escrevem de propósito. Conversas continuam conversas, decisões que merecem ser guardadas ficam escritas.
Customize Agents
Os agentes salvos são os membros do diretório. Construa os papéis de que seu projeto precisa: eles viram os endereços para os quais seus agentes escrevem.
Para se aprofundar
As melhores ferramentas para rodar vários agentes de código em 2026
Conductor, Crystal, Claude Squad, Vibe Kanban, AgentsRoom: uma comparação honesta das melhores ferramentas para rodar vários agentes de código em paralelo em 2026.
Como Escalar Agentes de Codificação de IA em uma Equipe de Desenvolvimento
Um desenvolvedor com um agente de codificação é uma história de produtividade. Cinco desenvolvedores com vinte agentes é um problema de coordenação. Aqui está o que quebra primeiro quando uma equipe se expande, e a configuração que se mantém: arquivos de contexto comprometidos, propriedade clara dos arquivos, revisão por raio de explosão e custo que você pode realmente ver.
Como se Comunicar com os seus Agentes de IA: Claude, Codex, Antigravity, Grok Build
O código já não é o gargalo, a comunicação é. Veja como falar com os seus agentes de IA Claude, Codex, Antigravity e Grok Build para entregar mais rápido, com mais precisão e gastando menos tokens.
Dê uma caixa de entrada aos seus agentes
Baixe o AgentsRoom, abra um projeto, e deixe os agentes que você já salvou começarem a se escrever em todas as CLIs que você roda.
App complementar: acompanhe seus agentes em qualquer lugar
Use Claude, Codex, Antigravity CLI ou outro provedor de IA.
Envie bugs e pedidos direto para o seu backlog público.