Control Room (antes War Room de agentes de IA): Claude, Codex y Gemini en paralelo

Qué es una Control Room de agentes de IA

Una Control Room es una sala con nombre en el panel auxiliar derecho. Muestra u oculta el panel con Alt+Ctrl+B (⌥⌘B en Mac). Agrega un miembro con el botón Control Room del encabezado de su panel, donde eliges o creas una sala, o usa 'Add all active panes' en la pestaña Members.

Cuando un agente se une, se escribe un mensaje de introducción en su panel. Después aparece un chip del miembro en la pestaña Members con la insignia "sin handshake" hasta que el agente hace su primera llamada a una herramienta, y entonces pasa a un punto de estado.

Una sala es un servidor MCP compartido al que se conectan los procesos de ambos agentes. Lo que cuenta es la membresía, no la cercanía física. Un panel de Claude Code en un espacio de trabajo y un panel de Codex en la carpeta de otro proyecto pueden compartir sala, porque una Control Room es un concepto de mensajería, no una disposición de paneles divididos.

Puedes tener varias salas a la vez, cada una con su propia lista de miembros y su propia transcripción. Un panel está en una sola sala a la vez: para mover un agente, usa el botón Control Room de su encabezado y elige la otra sala.

El panel tiene dos pestañas: Members (nombre, carpeta, ícono del agente y estado de conexión de cada miembro) y Discussion (composer más transcripción). En el composer, tú, el Moderator, eliges un destino (un agente o "Todos") y un modo.

Probe envía un mensaje. Execute pega un prompt en la terminal de ese agente y lo ejecuta allí. Los agentes tienen las mismas dos herramientas en sentido contrario, así que pueden hacer un probe a otro agente o pasarle un execute.

Para quién es una Control Room

Si usas un agente en un repositorio, sáltatela. Un solo panel de Claude Code o Codex es más simple, y una Control Room añade una interfaz que no vas a tocar.

Empieza a valer la pena cuando una tarea se reparte entre dos responsables: un cambio de contrato en el backend que necesita el visto bueno del frontend, un bug que abarca dos microservicios en dos copias de trabajo distintas, o un agente que implementa mientras otro revisa el diff antes de publicarlo.

También supone que te sientes cómodo dejando que un agente de CLI ejecute comandos con poca supervisión durante unos minutos. El modo Execute existe para que un prompt de traspaso se escriba y se ejecute en la terminal de otro agente sin que lo vuelvas a teclear. Si prefieres releer cada línea que ejecuta un agente, quédate en el modo Probe o no uses Execute.

Solo rinde con agentes que admiten llamadas a herramientas MCP. MXterm Pro escribe su servidor MCP en la configuración de Claude Code (~/.claude.json), OpenAI Codex (~/.codex/config.toml) y OMP cada vez que arranca la app. Grok toma la entrada que MXterm escribe en el ~/.claude.json de Claude Code (comprobado con Grok 1.0.34).

Gemini CLI recibe el servidor por proyecto, escrito en .gemini/settings.json cuando se abre un panel de Gemini ahí. Sea cual sea el agente, tiene que ejecutarse en un panel de MXterm Pro, porque el token por panel que lo identifica ante el servidor sale de ese panel (su entorno en Claude Code, Codex y OMP, la entrada de settings.json en Gemini). Así llega el agente a las herramientas mxt_room.

Cualquier otro agente de CLI tienes que apuntarlo a mano a la dirección MCP y al token del panel, y no está verificado que así funcione.

Cómo se hablan los agentes entre sí

El mensaje de introducción le indica a cada agente que llame primero a mxt_room.list_peers. Su primera llamada exitosa a la Control Room confirma la conexión. Hasta entonces, los demás miembros lo ven como aún no conectado y no pueden escribirle.

Las cuatro herramientas son list_peers, send, read_inbox y claim. list_peers muestra quién está en la sala. send escribe a otro agente o al Moderator, con el modo "probe" para conversar o el modo "execute" para pasar una tarea ejecutable. read_inbox trae lo que tiene en cola. claim reserva los archivos que un agente va a editar, solo orientativo.

Un probe no se pega completo en la terminal del agente receptor. Un único probe en cola de 280 caracteres o menos, en una línea y sin « », se inserta en un aviso de una línea ("[Control Room] Peer \"X\" sent probe message: « ... »"), así que el agente no necesita una segunda llamada a una herramienta. Si es más largo, tiene varias líneas o está en cola junto a otros, el aviso le indica al agente que llame a read_inbox.

El tope de tamaño y el paso por el inbox evitan que la charla entre agentes infle sin que te des cuenta la ventana de contexto de un agente, como pasaría si se pegara una conversación completa entre pares.

La entrega espera a que el panel quede inactivo. Se vigila la actividad de salida y el aviso se escribe solo tras unos 3 segundos de silencio.

Si escribiste una línea en el panel y no la enviaste, o pulsaste una tecla en el panel enfocado en los últimos 6 segundos, MXterm Pro retiene la entrega hasta que envíes o borres la línea, o hagas clic en Enviar ahora en el panel. Mientras tanto, la pestaña Members muestra un contador de mensajes retenidos, para que un mensaje en cola nunca caiga en medio de lo que estás escribiendo.

Tú, la persona que usa MXterm Pro, también eres un par. "Moderator" es un par fijo al que cualquier agente puede hacer un probe cuando necesita una decisión que otro agente no puede tomar por su cuenta. Un execute enviado al Moderator se rechaza de entrada, porque no hay terminal donde ejecutarlo.

El texto que MXterm Pro escribe en un panel en nombre de otro agente se limpia de secuencias de escape ANSI y caracteres de control, y un probe mostrado en línea también pierde los delimitadores « ». El mensaje completo queda en el inbox tal como se envió. Esto reduce la probabilidad de que el texto de otro agente se lea como una instrucción o se salga de la cita mostrada en el aviso; no es un límite de seguridad.

Un ejemplo real: dos agentes negocian el contrato de una API

Un caso típico: un panel de Claude Code abierto en un repositorio de backend y uno de Codex en el de frontend (o ambos en un mismo espacio de trabajo). Agrega los dos agentes a la sala con el botón Control Room del encabezado de cada panel, o con 'Add all active panes' en la pestaña Members. Cada uno recibe un mensaje de introducción y muestra la insignia "sin handshake" hasta que hace su primera llamada a una herramienta.

En el panel de Claude escribes algo como: "El frontend necesita created_at en la respuesta de /users. Habla del cambio de contrato con tu par de la Control Room hasta que se pongan de acuerdo y luego pásale el cambio con el modo execute."

Claude hace un probe a Codex, Codex lee su inbox y responde, y el intercambio se ve en la transcripción de Discussion. Lo sigues en vivo en lugar de pasar mensajes a mano.

Cuando se ponen de acuerdo, Claude le envía a Codex un execute con el cambio concreto. Se pega en el panel de Codex y se ejecuta allí, no en el de Claude.

Quitar a un agente surte efecto al instante. Si haces clic en la X del chip de un miembro (o usas el menú Control Room de su panel), cualquier mensaje que un par intente enviarle falla con "not in the Control Room". La membresía se revoca de inmediato, no solo se oculta en la interfaz.

El aislamiento con git worktree mantiene a los agentes fuera de la rama del otro

El aislamiento con worktrees es una casilla aparte, opcional, en el composer de nueva pestaña, desactivada por defecto. Activa Aislar funciones en git worktrees y, en un repositorio git, cada panel de agente de esa pestaña nueva se crea en su propio worktree <repo>/.worktrees/<slug> en lugar de en la raíz del repositorio.

En una carpeta que no es un repositorio git, los paneles usan la carpeta tal cual y aparece un aviso. Los paneles de shell normales se quedan en la raíz del repositorio en ambos casos.

MXterm Pro agrega .worktrees/ al .gitignore del repositorio. Cada panel de agente también recibe una rama nueva swarm/<adjective>-<noun>, por ejemplo swarm/brave-otter.

Esto ayuda cuando dos agentes de la misma sala editan el mismo repositorio. Un git worktree por agente reduce la probabilidad de que la edición a medias o el cambio de rama de un agente aparezca en el diff de otro en plena tarea. Las ramas resultantes las fusionas tú, porque MXterm Pro no fusiona worktrees automáticamente.

El exportador Reporte (.md)

Haz clic en Reporte (.md) en el encabezado de la pestaña Discussion, junto a Clear, y MXterm Pro escribe un reporte en Markdown, no solo un registro de chat en bruto.

El archivo empieza con una tabla de miembros (nombre del agente, modelo o id del agente, directorio de trabajo). Sigue una sección de diálogo que agrupa los mensajes consecutivos bajo un encabezado con marca de tiempo por cada turno de agente. Cada execute, y cada probe enviado a un par con nombre, lleva la etiqueta ⚡ EXECUTE o 📢 PROBE con su destino. Las entradas, salidas y otros eventos de la sala aparecen como líneas de evento del sistema.

El archivo deja fuera a propósito el ID de terminal de cada panel, porque ese valor es también el bearer token MCP del panel y el reporte está pensado para pasárselo a otra persona, como un compañero, un ticket o tus propias notas.

El exportador tiene acceso completo en ambos planes. MXterm Pro pone el límite en la cantidad de agentes que puedes meter en una sala, no en la exportación en sí.

Free vs. Pro

Por defecto, el plan Free limita una Control Room a 2 miembros. Si intentas agregar un tercero, MXterm Pro lo bloquea en el cliente y te pide que pases a Pro. No lo permite en silencio para fallar después.

Pro quita el tope: agentes ilimitados por sala. El número de salas nunca tuvo tope. El exportador Reporte (.md) es igual en ambos planes, porque el tope es el tamaño de la sala, no lo que puedes hacer con ella una vez armada.

Control Room frente a configuraciones manuales de varias terminales, Warp y frameworks multiagente

iTerm2 y tmux son el punto de partida: gratis o de código abierto, con buena división de paneles, totalmente programables y sin que tengas que confiar en nada más que en tu propia máquina. Lo que no te dan es un bus de mensajes.

Si dos agentes en dos paneles tienen que coordinarse, el bus de mensajes eres tú. Copias un error de un panel, lo pegas en el otro y llevas la cuenta de quién aceptó qué. Nada registra el intercambio a menos que guardes tu propio scrollback.

Warp es una terminal con IA muy pulida y con su propia orquestación multiagente: un agente padre crea y coordina agentes hijos, que pueden ejecutar Claude Code o Codex. Es un modelo de crear y delegar. La Control Room funciona distinto: tú inicias cada agente en su propio panel, y los agentes se escriben entre ellos y contigo, el Moderator, a través de una sala compartida.

Frameworks como AutoGen o CrewAI están hechos para orquestar agentes entre sí, posiblemente con más estructura que un bus de mensajes probe/execute. Pero son librerías de Python que escribes y ejecutas desde un notebook o un punto de entrada de CLI. No te dan paneles de terminal PTY reales que puedas ver desplazarse, donde entrar y escribir en plena conversación.

Aquí la Control Room de agentes de IA ofrece algo más acotado: paneles de terminal reales, donde cada agente es una sesión de CLI viva y no una llamada de API envuelta. Entre ellos hay un bus de mensajes y un rol de Moderator, todo dentro de la ventana donde ya usas tus terminales.

Es una alternativa a pasar mensajes entre paneles a mano. No reemplaza un framework de orquestación con scripts si ese es tu problema.

Límites que conviene conocer antes de empezar

La Control Room no inicia un debate por sí sola: tienes que pedirle a un agente que haga un probe a su par y siga. Es un bus de mensajes y una interfaz alrededor, no un planificador multiagente autónomo.

Un panel de shell normal puede unirse a una sala, pero no ejecuta un cliente MCP, así que el composer no permite enviarle un execute. Un prompt pegado ahí se ejecutaría como comandos de shell literales. Un panel de shell es un espectador en la sala, no un par de verdad.

Cada agente extra es otro proceso de CLI completo que gasta su propia cuota de modelo, así que una sala de cuatro agentes ejecuta cuatro sesiones de agente separadas. Reserva las salas multiagente para tareas que necesiten un segundo punto de vista, no para el trabajo rutinario de un solo agente.

Primeros pasos

Agrega dos agentes a una sala con el botón Control Room del encabezado de cada panel. Eso también abre el panel derecho en la pestaña Control Room (Alt+Ctrl+B o ⌥⌘B en Mac). Empieza con dos agentes apuntando a dos carpetas distintas, para ver un probe y un execute una vez antes de intentar algo más ambicioso. La página de Control Room da la visión general y los documentos de agentes y Control Room la referencia.

El tope de 2 miembros del plan Free solo se vuelve una limitación cuando una tarea necesita un tercer participante.