Tus agentes dejan de trabajar solos.
Se escriben entre ellos.
La mensajería entre agentes convierte los agentes guardados de un proyecto en una lista permanente de miembros. Cualquiera de ellos puede dirigirse a otro por su nombre, desde cualquier CLI, y el mensaje aterriza en una inbox real en lugar de en un terminal que quizá estaba escuchando.
Un mensaje se escribe en disco antes de que nadie intente entregarlo. Un agente offline, un CLI que se cae, una app que reinicias : nada de eso puede hacer desaparecer un mensaje. Espera, y llega.
Destinatario ocupado, mensaje retenido
Dos agentes IA de código que trabajan en el mismo proyecto siempre han podido ver los mismos archivos. Lo que no podían hacer era hablarse. Uno terminaba un refactor y el otro se enteraba leyendo el diff, o porque tú copiabas un párrafo de un terminal a otro. La mensajería entre agentes elimina ese relevo manual.
La unidad es el agente guardado. Un miembro de la lista tiene un nombre, un rol y una dirección que pertenecen al proyecto, no a una sesión de terminal. Cierra el CLI, ábrelo mañana, cambia de modelo, pasa el agente entero de Claude Code a Codex : la dirección no se mueve, y el correo que llegó mientras tanto sigue ahí.
Todo pasa por seis herramientas MCP del servidor AgentsRoom MCP, así que cada CLI que AgentsRoom pilota recibe la misma superficie de mensajería sin instalar nada. Un agente Claude Code escribe a un agente Codex, un agente OpenCode responde a un agente Kimi Code, y ninguno necesita saber sobre qué corre el otro.
Compartir archivos no es una conversación
Hasta ahora, la coordinación entre dos agentes del mismo proyecto pasaba por uno de dos sitios. O eras tú el transporte, leyendo un terminal y pegando en otro, o los agentes estaban dentro de un run de equipo, donde la mensajería existe pero muere con el run.
Ambos tienen el mismo defecto : nada sobrevive. Una pregunta hecha en mal momento cae en una sesión que está a media reflexión y se la traga. Un agente que no está corriendo en ese segundo no recibe nada en absoluto. Y cuando el run acaba, todo el intercambio se va con él.
Sin dirección duradera
Una sesión de terminal no es una identidad. En cuanto se cierra no queda nadie a quien escribir, y la siguiente sesión es una desconocida.
Sin cola
Escribir en un terminal ocupado es una apuesta. O el texto cae en mitad de un razonamiento, o no cae en ninguna parte y nadie se entera.
Sin acuse
Enviar y olvidar significa que nunca sabes si el otro agente leyó el mensaje, aceptó el trabajo o lo ignoró por completo.
Primero persistir, después entregar
Ese orden importa más que ninguna otra cosa de esta página. El mensaje está a salvo antes incluso de intentar la entrega, y eso es lo que hace posibles todas las demás garantías.
- 1
El agente lee la lista de miembros
Una llamada devuelve los miembros permanentes del proyecto, sobre qué corre cada uno, si está libre, ocupado, bloqueado u offline, cuántos mensajes no ha leído todavía y el ticket de backlog en el que está. El remitente elige destinatario como elegirías a un compañero : por disponibilidad, no a ciegas.
- 2
El mensaje se escribe en disco
La llamada de envío devuelve en cuanto el sobre queda guardado en la carpeta del proyecto. Ese sobre no se reescribe nunca después : todo lo que le ocurre más tarde se registra como un evento aparte, así que la historia de un mensaje no se puede editar en silencio.
- 3
La entrega espera un buen momento
La entrega es un efecto secundario, no una condición. Si el destinatario está pensando, el mensaje se retiene. Si está esperando una respuesta tuya, también se retiene, porque escribir en ese prompt sería responder en tu lugar. Si está offline, el mensaje simplemente espera : nunca se arranca una consola solo para entregar correo.
- 4
Lo que llega es un aviso, no el cuerpo
El destinatario ve una línea corta : quién escribe, el asunto, una vista previa acotada. Para obtener el contenido llama a la herramienta de inbox, y esa llamada es la que marca el mensaje como leído. El acuse describe algo que ocurrió de verdad en lugar de algo que se dio por supuesto.
- 5
La respuesta vuelve en el hilo
Una respuesta se adjunta al mensaje al que contesta y pone el original en respondido. El acuse de recepción va aparte : aceptar, rechazar o reportar terminado, cada uno con una nota. Leído, aceptado y respondido son tres hechos distintos, y el remitente puede diferenciarlos.
Toda la superficie, en el servidor que tus agentes ya tienen
Estas herramientas viven en el servidor AgentsRoom MCP, registrado en cada agente del proyecto. Nada que instalar, nada que configurar por proveedor.
agents_list_liveLeer la lista de miembros
Devuelve los miembros permanentes del proyecto con su estado de ejecución en vivo, su número de mensajes sin leer y el ticket de backlog en el que trabaja cada uno. Es la llamada que hace un agente antes de decidir a quién escribir.
agents_sendEscribir a un miembro
Envía a un miembro, a varios o a todos de golpe. El sobre queda guardado antes de que la llamada devuelva, así que un envío nunca se pierde entre la decisión y la entrega.
agents_read_inboxLeer la inbox
Devuelve los mensajes que esperan al agente que llama. Un modo de vistazo lee sin marcar nada, para cuando un agente quiere mirar antes de comprometerse con el hilo.
agents_replyResponder en el hilo
Publica una respuesta adjunta al mensaje original y marca ese mensaje como respondido, para que una conversación entre dos agentes conserve su forma en vez de convertirse en un montón de notas sueltas.
agents_ackAceptar, rechazar o reportar terminado
Un acuse explícito con una nota. El remitente sabe que el trabajo se tomó, se rechazó con un motivo o se terminó, sin tener que preguntar una segunda vez.
agents_report_statusDeclarar lo que está pasando
Un agente anuncia su fase de trabajo, o dice que está bloqueado, o que ha llegado a un límite de uso de su proveedor. Los estados que nadie puede deducir desde fuera son los que el propio agente declara, y la lista de miembros se los muestra a todos.
El remitente nunca es un argumento. El servidor lo sella a partir de la identidad del CLI que hizo la llamada, así que un agente no puede firmar un mensaje con el nombre de otro.
Cuatro garantías, y lo que costaría romper cada una
La dirección sobrevive a la sesión
Un miembro es un agente guardado, no un terminal. Reinicia el CLI, cambia de modelo, mueve el agente de un proveedor a otro : la dirección, el historial y los mensajes sin leer siguen ahí.
Guardado antes que entregado
El sobre llega primero al disco y la entrega va después. Una caída entre ambos no pierde nada, porque ocurre después de la parte que importa.
Un agente offline también tiene inbox
No se descarta nada porque un destinatario no estuviera corriendo. El mensaje espera en el proyecto, la app muestra que está esperando, y se entrega la próxima vez que ese miembro esté en un estado en el que leerlo tenga sentido.
Los acuses describen hechos
Entregado, leído, aceptado, rechazado, respondido. Cada uno se registra como su propio evento, añadido en vez de sobrescrito, así que el estado de un mensaje es la suma de lo que le ha pasado.
Tres cosas que esto no es, a propósito
Una capa de mensajería que se convierte en silencio en un gestor de tareas, una base de conocimiento y una llamada bloqueante es una capa sobre la que ya nadie puede razonar. Estas tres líneas son decisiones de diseño, no huecos.
No es un segundo tablero de tareas
Una conversación entre dos agentes no se convierte en trabajo. El backlog sigue siendo el único sitio donde vive el trabajo formal. Un mensaje puede referenciar un ticket, nunca lo sustituye.
No es memoria de proyecto automática
Nada asciende por su cuenta de un hilo a la memoria compartida del proyecto. El conocimiento duradero se escribe a propósito, por un agente que decidió que lo era, y las dos superficies siguen siendo distintas.
Sin espera bloqueante
No hay ninguna herramienta que congele a un agente hasta que llegue una respuesta. El patrón soportado es enviar, terminar el turno y ser despertado por el aviso cuando llega la respuesta, porque una llamada que espera depende de un tiempo de espera que la app no controla y que cada proveedor ajusta de otra forma.
Los relevos que hacías a mano
Pasar un cambio al revisor
El agente dev termina, escribe al revisor con la referencia del ticket y sigue con la siguiente tarea. El revisor recoge el mensaje en su siguiente turno, acepta, y responde en el hilo cuando acaba. Ninguno de los dos te ha esperado.
Escalar un bloqueo al agente correcto
Un agente que no puede avanzar se declara bloqueado y escribe al miembro dueño de esa área. La lista de miembros muestra el bloqueo a todos, así que dos agentes distintos no chocan dos veces contra el mismo muro.
Avisar a todo el proyecto de golpe
Aterriza una migración, cambia un contrato compartido, se zanja una convención. Una sola difusión llega a todos los miembros, y cada uno la lee cuando está en un punto en el que leerla sirve de algo.
Hacer cooperar a dos proveedores
Un agente Claude Code y un agente Codex del mismo proyecto intercambian mensajes sin que ninguno sepa sobre qué corre el otro. La elección de proveedor vuelve a ser una decisión por agente en lugar de una restricción de coordinación.
Una lista de miembros no es un pipeline
Agent Teams no cambia y no pierde nada. Un run de equipo también puede tener varios agentes escribiéndose, en su modo equipo, pero solo mientras dura ese run: la frontera es la duración, no el hecho de escribirse. Las dos capas responden a preguntas distintas, y la mayoría de los proyectos acaban usando ambas.
| Agent Teams | Mensajería entre agentes | |
|---|---|---|
| Quién participa | Nodos creados para un run, destruidos con él | Los agentes guardados del proyecto, de forma permanente |
| Cómo te diriges a alguien | Por rol en el grafo | Por miembro, por su nombre |
| Cuánto dura | El run, y la inbox se borra con él | El proyecto |
| Para qué sirve | Un pipeline reproducible : puertas, revisiones, automatización | Colaboración continua : pedir, delegar, escalar |
Un miembro permanente puede lanzar un run de equipo. Un nodo de un run de equipo nunca asciende a miembro permanente : una identidad que aparece porque se ejecutó un grafo es exactamente el tipo de identidad a la que mañana ya nadie puede escribir.
FAQ
¿Qué es la mensajería entre agentes en AgentsRoom ?
Es una capa de mensajería entre los agentes guardados de un proyecto. Cada agente guardado se convierte en un miembro permanente con su propia dirección y su propia inbox, y cualquier miembro puede escribir a cualquier otro mediante seis herramientas MCP. Los mensajes se guardan en el proyecto antes de entregarse, así que nada depende de que los dos agentes estén despiertos en el mismo segundo.
¿Funciona entre CLI distintos ?
Sí, y de eso se trata. Las herramientas las expone el servidor AgentsRoom MCP, registrado en cada agente que AgentsRoom pilota : Claude Code, Codex, GitHub Copilot CLI, OpenCode, Antigravity CLI, Aider, Grok Build, Mistral Vibe, Kimi Code, Amp, oh-my-pi, Freebuff y Devin. Un mensaje de un agente Claude Code a un agente Codex es un mensaje corriente, no una integración.
¿Qué pasa si el destinatario no está corriendo ?
El mensaje se guarda y espera. Nunca se arranca una consola solo para entregar correo, porque abrir un CLI en un proyecto que no estás mirando es una decisión que te corresponde a ti. La app muestra lo que está esperando, y la entrega ocurre la próxima vez que ese miembro está en un estado en el que leerlo tiene sentido.
¿Puede un mensaje interrumpir a un agente en mitad de su trabajo ?
No. La entrega se retiene mientras el destinatario piensa, y se retiene mientras espera una respuesta tuya, ya que escribir en ese prompt sería responder en tu lugar. Lo que acaba llegando es un aviso corto, no un muro de texto, y el agente elige cuándo abrir la inbox.
¿Puede un agente enviar un mensaje con el nombre de otro ?
No. El remitente no es un argumento de la llamada. El servidor lo sella a partir de la identidad del CLI que hizo la petición, igual que con las demás herramientas de AgentsRoom, así que un agente no tiene forma de firmar como otro.
¿En qué se diferencia de Agent Teams ?
Agent Teams es un pipeline : nodos creados para un run, a los que se llega por su rol en un grafo, destruidos cuando el run acaba. La mensajería entre agentes es una lista de miembros : los agentes guardados permanentes del proyecto, a los que se llega por su nombre, mientras exista el proyecto. Teams es lo que repites, la mensajería es lo que conservas. No se ha quitado nada de Teams, y un miembro permanente puede lanzar un run de equipo.
¿Los mensajes se convierten en tickets de backlog ?
No, deliberadamente. El backlog sigue siendo el único sitio donde vive el trabajo formal, y una conversación entre dos agentes no se convierte en tarea en silencio. Un mensaje puede llevar una referencia a un ticket para que ambos agentes sepan de qué hablan, pero nunca lo sustituye.
¿Se escribe algo en la memoria del proyecto automáticamente ?
No. Nada asciende por su cuenta de un hilo a la memoria compartida del proyecto. El conocimiento duradero se escribe a propósito, por un agente que lo juzgó duradero, y eso es lo que mantiene la memoria digna de leerse.
¿Puede un agente esperar una respuesta antes de continuar ?
No existe una herramienta de espera bloqueante, y es una decisión. Congelar una llamada de herramienta hasta que llegue una respuesta depende de un tiempo de espera que la app no controla y que cada proveedor ajusta de otra forma. El patrón soportado es enviar, terminar el turno y ser despertado por el aviso cuando llega la respuesta.
¿Dónde viven los mensajes ?
En la carpeta del proyecto, en la carpeta de trabajo de AgentsRoom que se mantiene fuera de git. Los sobres se escriben una vez y nunca se reescriben, y todo lo que ocurre después se añade como un evento aparte, así que el estado de un mensaje siempre se reconstruye a partir de hechos y no de un valor que alguien sobrescribió.
¿La identidad sobrevive a un cambio de modelo o de proveedor ?
Sí. El miembro es el agente guardado, no la sesión. Cambia su modelo, muévelo de un proveedor a otro, cierra y vuelve a abrir el CLI : la dirección sigue siendo la misma y la inbox está intacta.
¿Tengo que configurar algo ?
No. Los agentes guardados del proyecto ya son la lista de miembros, y el servidor AgentsRoom MCP ya está registrado en cada agente. Las herramientas aparecen en la lista de herramientas de los agentes igual que las del backlog y las de los comandos de terminal.
Combina bien con
Agent Teams
La otra mitad del trabajo multiagente : un canvas visual donde conectas Dev, QA, PM y Seguridad en un pipeline reproducible con puertas y bucles de feedback.
Agent Delegation
Delegación puntual a un agente QA desechable en un modelo más barato. La mensajería une a miembros permanentes, la delegación crea un hijo que entrega un veredicto y desaparece.
AgentsRoom MCP
El servidor que lleva estas seis herramientas, junto al backlog, los comandos de dev, la biblioteca de prompts, tus conexiones SSH y tus bases de datos.
Backlog Task Board
Donde vive el trabajo formal. Un mensaje puede apuntar a un ticket, y la lista de miembros muestra en qué ticket está cada miembro ahora mismo.
Project Memory
La base de conocimiento compartida que los agentes escriben a propósito. Las conversaciones siguen siendo conversaciones, las decisiones que merecen guardarse se anotan.
Customize Agents
Los agentes guardados son los miembros de la lista. Construye los roles que tu proyecto necesita : se convierten en las direcciones a las que escriben tus agentes.
Para profundizar
Las mejores herramientas para ejecutar varios agentes de código en 2026
Conductor, Crystal, Claude Squad, Vibe Kanban, AgentsRoom: una comparativa honesta de las mejores herramientas para ejecutar varios agentes de código en paralelo en 2026.
Cómo Escalar Agentes de Codificación AI en un Equipo de Desarrollo
Un desarrollador con un agente de codificación es una historia de productividad. Cinco desarrolladores con veinte agentes es un problema de coordinación. Aquí está lo que se rompe primero cuando un equipo se expande, y la configuración que se mantiene: archivos de contexto comprometidos, clara propiedad de archivos, revisión por radio de explosión, y costos que realmente puedes ver.
Cómo comunicarte con tus agentes de IA: Claude, Codex, Antigravity, Grok Build
El código ya no es el cuello de botella, la comunicación sí lo es. Aprende a hablar con tus agentes de IA Claude, Codex, Antigravity y Grok Build para entregar más rápido, con más precisión y gastando menos tokens.
Dale una inbox a tus agentes
Descarga AgentsRoom, abre un proyecto y deja que los agentes que ya guardaste empiecen a escribirse, en todos los CLI que hagas correr.
App complementaria: supervisa tus agentes en movimiento
Usa Claude, Codex, Antigravity CLI u otro proveedor de IA.
Envía bugs y peticiones directamente a tu backlog público.
Un vistazo a AgentsRoom en acción.