Vários agentes de IA no terminal com a Control Room (antes War Room)

O que uma Control Room de agentes de IA realmente é

Uma Control Room é uma sala com nome no painel auxiliar da direita. Abra ou feche o painel com Alt+Ctrl+B (⌥⌘B no Mac). Adicione um membro com o botão Control Room no cabeçalho do painel dele, onde você escolhe ou cria uma sala, ou use "Add all active panes" na aba Members.

Quando um agente entra, uma mensagem de introdução é digitada no painel dele. Um chip de membro aparece então na aba Members com o selo "sem handshake" até o agente fazer a primeira chamada de ferramenta, e depois com um indicador de status.

Uma sala é um servidor MCP compartilhado ao qual os dois processos de agente se conectam. O que conta é a participação, não a proximidade física. Um painel do Claude Code num espaço de trabalho e um painel do Codex numa pasta de projeto diferente podem dividir uma sala, porque a Control Room é um conceito de mensagens, não um layout de painéis divididos.

Você pode ter várias salas ao mesmo tempo, cada uma com a sua lista de membros e a sua transcrição. Um painel fica em uma sala por vez; para mover um agente, use o botão Control Room no cabeçalho do painel dele e escolha a outra sala.

O painel tem duas abas: Members (nome, pasta, ícone do agente e estado da conexão de cada membro) e Discussion (Composer mais transcrição). No Composer, você, o Moderator, escolhe um destino (um agente ou "Todos") e um modo.

Probe envia uma mensagem. Execute cola um prompt no terminal daquele agente e o executa lá. Os agentes têm as mesmas duas ferramentas no sentido inverso, então podem fazer um probe num colega ou passar um execute para ele.

Para quem serve a Control Room

Se você roda um agente em um repositório, pule isto. Um único painel do Claude Code ou do Codex é mais simples, e a Control Room só acrescenta uma interface que você não vai usar.

Ela compensa quando uma tarefa se divide entre dois responsáveis: uma mudança de contrato no backend que precisa do aval do frontend, um bug que atravessa dois microsserviços em duas cópias de trabalho diferentes, ou um agente implementando enquanto um segundo revisa o diff antes de ele ir para produção.

Ela também pressupõe que você se sinta à vontade com um agente de CLI executando comandos com supervisão limitada por alguns minutos de cada vez. O modo Execute existe para que um prompt de passagem de tarefa seja digitado e executado no terminal de um colega sem você redigitar. Se você prefere reler cada linha que um agente executa, fique no modo Probe ou não use o Execute.

Ela só vale a pena com agentes que aceitam chamadas de ferramentas MCP. O MXterm Pro grava o servidor MCP dele na configuração do Claude Code (~/.claude.json), do OpenAI Codex (~/.codex/config.toml) e do OMP toda vez que o app inicia. O Grok usa a entrada que o MXterm grava no ~/.claude.json do Claude Code (verificado com o Grok 1.0.34).

O Gemini CLI recebe o servidor por projeto, gravado em .gemini/settings.json quando um painel do Gemini abre ali. Seja qual for o agente, ele precisa rodar num painel do MXterm Pro, porque o token por painel que o identifica no servidor vem desse painel (o ambiente, no caso do Claude Code, do Codex e do OMP; a entrada em settings.json, no do Gemini). É assim que o agente alcança as ferramentas mxt_room.

Qualquer outro agente de CLI precisa ser apontado à mão para o endereço MCP e o token do painel, e não foi verificado se isso funciona.

Como os agentes realmente conversam entre si

A mensagem de introdução diz a cada agente para chamar mxt_room.list_peers primeiro. A primeira chamada bem-sucedida à Control Room confirma a conexão e, até isso acontecer, os outros membros veem o agente como ainda não conectado e não conseguem enviar mensagem a ele.

As quatro ferramentas são list_peers, send, read_inbox e claim. list_peers mostra quem está na sala. send envia uma mensagem a um colega ou ao Moderator, com o modo "probe" para discussão ou o modo "execute" para passar uma tarefa executável. read_inbox busca o que está na fila do agente. claim reserva os arquivos que o agente vai editar, apenas como aviso consultivo.

Um probe não é colado inteiro no terminal do agente que o recebe. Um único probe na fila de até 280 caracteres, em uma linha e sem « », entra dentro de um aviso de uma linha ("[Control Room] Peer \"X\" sent probe message: « ... »"), então o agente não precisa de uma segunda chamada de ferramenta. Qualquer coisa maior, com várias linhas ou na fila junto com outros recebe um aviso pedindo que o agente chame read_inbox.

O limite de tamanho e o desvio pela caixa de entrada evitam que a conversa entre agentes infle em silêncio a janela de contexto de um agente, o que acontece quando se cola a conversa inteira de um colega.

A entrega espera o painel ficar ocioso. A atividade de saída é monitorada, e um aviso só é digitado depois de cerca de 3 segundos de silêncio.

Se você digitou uma linha no painel e não a enviou, ou apertou uma tecla no painel em foco nos últimos 6 segundos, o MXterm Pro retém a entrega até você enviar ou limpar a linha, ou clicar em Entregar agora no painel. Enquanto isso, a aba Members mostra a contagem de mensagens retidas, então uma mensagem na fila nunca cai no meio do que você está digitando.

Você, a pessoa que usa o MXterm Pro, também é um colega. O "Moderator" é um colega fixo que qualquer agente pode consultar com um probe quando precisa de uma decisão que um agente colega não pode tomar sozinho. Um execute enviado ao Moderator é rejeitado de cara, porque não há terminal onde executá-lo.

O texto que o MXterm Pro digita num painel em nome de um colega perde as sequências de escape ANSI e os caracteres de controle, e um probe exibido no aviso também perde os delimitadores « ». A mensagem completa continua na caixa de entrada como foi enviada. Isso reduz a chance de o texto de um colega ser lido como instrução ou de escapar da exibição entre aspas no aviso; não é uma fronteira de segurança.

Um exemplo prático: dois agentes negociando um contrato de API

Uma execução típica tem um painel do Claude Code aberto num repositório de backend e um painel do Codex no repositório de frontend (ou os dois num espaço de trabalho só). Adicione os dois agentes à sala com o botão Control Room no cabeçalho de cada painel, ou com "Add all active panes" na aba Members. Cada um recebe uma mensagem de introdução e mostra o selo "sem handshake" até fazer a primeira chamada de ferramenta.

No painel do Claude, você digita algo como: "O frontend precisa de created_at na resposta de /users. Discuta a mudança de contrato com seu colega da Control Room até vocês chegarem a um acordo, e depois passe a mudança para ele com o modo execute."

O Claude faz um probe no Codex, o Codex lê a caixa de entrada e responde, e o vaivém acontece na transcrição da aba Discussion. Você acompanha ao vivo, sem repassar nada na mão.

Quando os dois concordam, o Claude envia ao Codex um execute com a mudança concreta. Ele é colado no painel do Codex e roda lá, não no do Claude.

A remoção vale na hora. Se você clicar no X do chip de um membro (ou usar o menu Control Room do painel dele), qualquer mensagem que um colega tentar enviar a ele falha com "not in the Control Room". A participação é revogada de imediato, e não apenas escondida na interface.

O isolamento com git worktree mantém cada agente na própria branch

O isolamento com worktree é uma caixa de seleção separada e opcional no Composer de nova aba, desligada por padrão. Ative Isolar funcionalidades em git worktrees e, num repositório git, cada painel de agente dessa nova aba é criado no seu próprio worktree em <repo>/.worktrees/<slug>, em vez de na raiz do repositório.

Numa pasta que não é um repositório git, os painéis usam a própria pasta, com um aviso. Os painéis de shell comuns ficam na raiz do repositório de qualquer forma.

O MXterm Pro adiciona .worktrees/ ao .gitignore do repositório. Cada painel de agente também ganha uma nova branch swarm/<adjective>-<noun>, por exemplo swarm/brave-otter.

Isso ajuda quando dois agentes da mesma sala editam o mesmo repositório. Um git worktree por agente reduz a chance de que a edição pela metade ou a troca de branch de um agente apareça no diff de um colega no meio da tarefa. Você ainda faz o merge das branches resultantes por conta própria, porque o MXterm Pro não faz merge automático dos worktrees.

O exportador de Relatório (.md)

Clique em Relatório (.md) no cabeçalho da aba Discussion, ao lado de Limpar discussão, e o MXterm Pro grava um relatório em Markdown, não só um log bruto da conversa.

O arquivo começa com uma tabela de membros (nome do agente, modelo/id do agente, diretório de trabalho). Em seguida vem uma seção de diálogo que agrupa mensagens consecutivas sob um título com data e hora para cada turno de agente. Cada execute, e cada probe enviado a um colega nomeado, recebe a marca ⚡ EXECUTE ou 📢 PROBE com o destino. Entradas, saídas e outros eventos da sala aparecem como linhas de evento do sistema.

O arquivo deixa de fora de propósito o ID de terminal de cada painel, já que esse valor também serve de bearer token MCP do painel e o relatório é feito para ser entregue a outra pessoa, como um colega, um ticket ou suas próprias anotações.

O exportador está completo nos dois planos. O MXterm Pro limita o número de agentes que você pode pôr numa sala, não a exportação em si.

Free x Pro

Por padrão, o plano Free limita uma Control Room a 2 membros. Se você tentar adicionar um terceiro, o MXterm Pro bloqueia a entrada no próprio app e pede que você faça upgrade. Ele não deixa a entrada passar em silêncio para só falhar depois.

O plano Pro remove o limite: agentes ilimitados por sala. O número de salas nunca teve limite. O exportador de Relatório (.md) é o mesmo nos dois planos, já que o limite é no tamanho da sala, não no que você pode fazer com uma sala depois de montá-la.

Control Room x setups manuais com vários terminais, Warp e frameworks multiagente

iTerm2 e tmux são a referência: gratuitos ou de código aberto, com divisão de painéis sólida, totalmente programáveis e sem nada em que confiar além da sua própria máquina. O que eles não oferecem é um barramento de mensagens.

Se dois agentes em dois painéis precisam se coordenar, o barramento de mensagens é você. Você copia um erro de um painel, cola no outro e controla quem concordou com o quê. Nada registra a troca, a menos que você salve o seu próprio scrollback.

O Warp é um terminal de IA refinado, com orquestração multiagente própria: um agente pai cria e coordena agentes filhos, que podem rodar Claude Code ou Codex. É um modelo de criar e delegar. A Control Room tem outro formato: você inicia cada agente por conta própria no seu painel, e os agentes trocam mensagens entre si e com você, o Moderator, por uma sala compartilhada.

Frameworks como AutoGen ou CrewAI são feitos para orquestração entre agentes, com possivelmente mais estrutura do que um barramento de mensagens probe/execute. Mas são bibliotecas Python que você programa e executa a partir de um notebook ou de um ponto de entrada de CLI. Você não ganha painéis de terminal PTY reais, que dá para ver rolar, nos quais dá para entrar e digitar no meio da conversa.

Aqui, a Control Room oferece algo mais restrito: vários agentes de IA no terminal, em painéis reais, onde cada agente é uma sessão de CLI ao vivo e não uma chamada de API encapsulada, mais um barramento de mensagens e o papel de Moderator entre eles, integrados à janela onde você já roda seus terminais.

É uma alternativa a repassar mensagens entre painéis na mão. Não substitui um framework de orquestração por script, se esse for o seu problema.

Limites que vale conhecer antes de começar

A Control Room não inicia um debate sozinha: você precisa pedir a um agente que faça um probe no colega e continue. Ela é um barramento de mensagens e uma interface em volta dele, não um planejador multiagente autônomo.

Um painel de shell comum pode entrar numa sala, mas não roda um cliente MCP, então o Composer desativa o envio de um execute para ele. Um prompt colado ali rodaria como comandos de shell literais. Um painel de shell é espectador na sala, não um colega de verdade.

Cada agente extra é mais um processo de CLI completo usando a própria cota de modelo, então uma sala com quatro agentes roda quatro sessões de agente separadas. Reserve as salas multiagente para tarefas que precisam de um segundo ponto de vista, não para o trabalho rotineiro de um agente só.

Primeiros passos

Adicione dois agentes a uma sala com o botão Control Room no cabeçalho de cada painel. Isso também abre o painel da direita na aba Control Room (Alt+Ctrl+B ou ⌥⌘B no Mac). Comece com dois agentes apontados para duas pastas diferentes, para ver um probe e um execute acontecerem uma vez antes de tentar algo mais ambicioso. A página da Control Room traz a visão geral e a documentação de agentes e Control Room traz a referência.

O limite de 2 membros do plano Free só vira restrição quando uma tarefa precisa de um terceiro participante.