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 seis 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 fica retida. Se o destinatário está esperando uma resposta sua, a mensagem fica retida também, porque escrever naquele prompt seria responder no seu lugar. Se o destinatário está offline, a mensagem simplesmente espera: nenhum console é iniciado só para entregar correio.
- 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_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.

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.
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 seis 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 e Devin. 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. Nenhum console é iniciado só para entregar correio, porque abrir uma CLI em um projeto que você não está olhando é uma decisão que cabe a você. O aplicativo mostra o que está esperando, e a entrega acontece na próxima vez que aquele membro estiver em um estado em que ler faz sentido.
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.
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 seis 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.
Uma visão do AgentsRoom em ação.