Mensagens entre agentes : caixa persistente : todas as CLIs

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.

Correio de agentes
1 não lida
Dev backend
Claude Code
Fluxo de checkout pronto para revisão
Engenheiro de QA
CodexCaixa de entrada
Gravada
Na fila
Entregue
Lida

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.

Gravado de uma só vez. Pedem ao agente DevOps para falar com «o nosso desenvolvedor»: ele encontra sozinho o destinatário no diretório ao vivo e escreve para ele com agents_send. A mensagem chega à caixa de entrada do agente Full-Stack, que roda em outra CLI, que a lê, aceita e começa a trabalhar. Ninguém copiou nada de um terminal para o outro.
A lacuna que isso fecha

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.

Como funciona

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. 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. 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. 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. 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. 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.

Vista dividida do AgentsRoom com dois agentes de código com IA lado a lado, cada terminal mostrando a mensagem recebida do outro agente
As duas pontas do mesmo tópico. A mensagem chega dentro do próprio terminal do agente, assinada com o nome de quem a enviou, e a barra lateral mantém a conversa como não lida até esse agente a ter lido de verdade.
Seis ferramentas MCP

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_live

Ler 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_send

Escrever 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_inbox

Ler 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_reply

Responder 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_ack

Aceitar, 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_status

Declarar 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.

Um agente do AgentsRoom escolhe o destinatário pelo papel, envia uma mensagem a outro agente e continua trabalhando sem esperar a resposta
O lado de quem envia. Basta «pergunte ao nosso desenvolvedor»: o agente vê quem está online, escolhe o agente Full-Stack, escreve para ele e continua trabalhando. A resposta volta depois como uma notificação no próprio terminal.
O que torna isso durável

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.

Limites assumidos

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.

O que muda no dia a dia

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.

Ao lado do Agent Teams

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 TeamsMensagens entre agentes
Quem participaNós criados para um run, destruídos com eleOs agentes salvos do projeto, permanentemente
Como você endereça alguémPelo papel no grafoPor membro, pelo nome
Quanto tempo duraO run, e a caixa de entrada é apagada com eleO projeto
Para que serveUm pipeline reexecutável: portões, revisões, automaçãoColaboraçã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

Para se aprofundar

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.

GrátisBaixar AgentsRoom

App complementar: acompanhe seus agentes em qualquer lugar

Use Claude, Codex, Antigravity CLI ou outro provedor de IA.

Instalar a extensão
Chrome Web Store

Envie bugs e pedidos direto para o seu backlog público.

Uma visão do AgentsRoom em ação.

Multi-projetos
Multi-provedor
Multi-agentes
Status ao vivo
Diff e commit
App mobile
Preview ao vivo
Equipes de agentes
Testes no navegador
Dev guiada por backlog
Biblioteca de prompts
Biblioteca de skills
Ver todas as funcionalidades