Comunicación Multi-Agente: El Profesor X y los X-Men Como Sistema Distribuido
Cómo los agentes se comunican entre sí, qué formatos usan, y qué puede salir mal cuando varios agentes trabajan en simultáneo.
La mansión Xavier como arquitectura multi-agente
Pensá en la Mansión Xavier. Tenés al Profesor X sentado en Cerebro coordinando todo desde el centro. Tenés a Cíclope liderando misiones tácticas. A Tormenta controlando el clima. A Lobezno en campo. A Jean Grey haciendo exploración mental. Cada uno con poderes distintos, cada uno con su dominio de especialización.
Eso es exactamente un sistema multi-agente bien diseñado. Un orchestrator (Profesor X) que coordina, y sub-agentes especializados (los X-Men) que ejecutan tareas concretas. Pero hay algo que en las películas no se ve claramente: ¿cómo se comunican?
La comunicación entre agentes no es magia telepática. Es código. Y ese código tiene estructura, tiene formato, y tiene reglas que hay que conocer para el examen.
En el primer video del módulo vimos qué es el loop agéntico. En el segundo video, los patrones de coordinación. En el tercero, cómo funcionan las herramientas. En el cuarto, cómo parar un agente con seguridad. En el siguiente, cómo manejar el estado multi-turno. Ahora cerramos el Dominio 1 con el tema que une todo: la comunicación entre agentes.
Tres formas en que los X-Men se comunican
En un sistema multi-agente hay tres patrones básicos de comunicación. Cada uno tiene un caso de uso diferente, y el examen te va a preguntar cuál usarías en cada situación.
⚠️ La comunicación sub-agente → sub-agente es potente pero riesgosa. Si dos agentes se hablan directamente sin que el orchestrator lo sepa, podés tener decisiones inconsistentes. Usala con criterio y siempre logeá los mensajes.
Anatomía de un mensaje entre agentes
Un mensaje entre agentes no es texto libre. Tiene una estructura definida que permite que el agente receptor sepa qué tiene que hacer, con qué datos, y qué debe devolver.
Pensalo como las instrucciones que el Profesor X le transmite a Cíclope antes de una misión: no es 'andate a hacer algo por ahí'. Es un briefing completo: objetivo, contexto, restricciones, formato esperado de respuesta.
💡 EXAMEN: El campo 'contexto_previo' es crítico. Cuando el orchestrator le pasa una tarea a un sub-agente, le tiene que pasar también el contexto acumulado hasta ese momento. Sin contexto, el sub-agente trabaja en la oscuridad.
Cerebro: el message broker del sistema
En los cómics, Cerebro amplifica los poderes telepáticos del Profesor X para localizar mutantes en todo el mundo. En arquitectura multi-agente, el equivalente es un message broker: un componente central que enruta mensajes entre agentes, registra qué se envió, y garantiza que los mensajes lleguen.
No siempre necesitás un broker. Para sistemas simples, el orchestrator puede comunicarse directamente con cada sub-agente. Pero cuando tenés muchos agentes, tareas paralelas, o necesitás auditar la comunicación, un broker es invaluable.
Demo completo: sistema X-Men multi-agente
Ahora juntemos todo. El Profesor X como orchestrator, tres X-Men como sub-agentes especializados, y Cerebro como broker. Una misión de rescate con comunicación estructurada.
Fijate en el patrón: el Profesor X no ejecuta nada. Planifica con Claude, divide en tareas, y delega. Los sub-agentes ejecutan, reportan, y el orchestrator consolida. Esa separación de responsabilidades es el corazón del diseño multi-agente.
Qué puede salir mal cuando los X-Men no se comunican bien
Los X-Men tienen décadas de historia de misiones que salieron mal por problemas de comunicación. En sistemas multi-agente, los problemas son los mismos pero en código.
🚨 El loop de mensajes entre agentes es uno de los errores más difíciles de debuggear. Si no tenés TTL ni detección de ciclos, tu sistema puede correr indefinidamente sin error visible. Siempre logeá remitente + destinatario de cada mensaje.
Las 4 trampas del examen sobre comunicación multi-agente
Trampa 1: 'El orchestrator debe conocer todos los detalles de implementación de cada sub-agente'
FALSO. El orchestrator solo necesita saber qué puede hacer cada sub-agente (su interfaz), no cómo lo hace. Esta abstracción es lo que permite reemplazar un sub-agente sin cambiar el orchestrator. El Profesor X sabe que Lobezno puede rastrear — no necesita entender cómo funcionan sus sentidos mejorados.
Trampa 2: 'La comunicación directa entre sub-agentes siempre es más eficiente que pasar por el orchestrator'
DEPENDE. Es más rápido en tiempo de ejecución, sí. Pero rompe la observabilidad del sistema: el orchestrator no sabe qué acordaron los sub-agentes. Para el examen: comunicación directa entre sub-agentes es válida para coordinación táctica de bajo nivel, pero decisiones que afectan el objetivo global siempre deben pasar por el orchestrator.
Trampa 3: 'Un sistema multi-agente siempre es mejor que un agente único'
NO. La complejidad de comunicación tiene un costo. Para tareas simples, un agente único es más rápido, más fácil de debuggear, y menos propenso a errores. El multi-agente se justifica cuando las tareas son paralelizables, cuando requieren especialización diferente, o cuando el volumen de trabajo es demasiado para un solo contexto.
Trampa 4: 'Agregar más sub-agentes siempre mejora el rendimiento'
FALSO. Más agentes = más mensajes = más overhead de coordinación. Si las tareas no son genuinamente paralelas, agregar agentes puede hacer el sistema más lento. Este es el equivalente a poner a 10 personas a pintar una pared donde solo cabe una persona a la vez.
Cerrando el Dominio 1: lo que construiste en M1
Seis videos. Seis conceptos que forman el 27% del examen CCA-F. Tomemos un segundo para ver el mapa completo del Dominio 1.
Si dominás estos 6 conceptos del Dominio 1, ya tenés el 27% del examen bajo control. El próximo módulo arranca con el Dominio 2: Tool Design y MCP. Spoiler: vas a aprender a construir herramientas desde cero, no solo usarlas.