Multi-Agent Coordination 2026: El 90% de los Sistemas Multi-Agente No lo Son

# El 90% de los Sistemas Multi-Agente que Ves en Producción No Son Multi-Agente

Son un solo LLM al que le pedimos que finja ser varias personas. Y funciona exactamente tan mal como suena.

La creencia popular es que "más agentes = más capacidad". Que cualquier sistema que use múltiples prompts es multi-agente. La industria te vende que añadir agentes es la solución genérica para todo. Ves tutoriales que conectan tres "agentes" en diez líneas de código y te prometen que eso es el futuro de la IA.

*La realidad es la contraria. *

Tres agentes mal coordinados producen peor output que un solo agente bien diseñado.

Boris Cherny, el líder del equipo que construyó Claude Code, lo dijo claro en Meta @Scale este junio de 2026: los agentes están empezando a promptear a otros agentes. El patrón que funciona no es juntar LLMs. Es construir loops recursivos con subagentes especializados que operan en contextos aislados, gestionados por un supervisor. Cherny describió cómo, en su propio entorno de desarrollo, mantiene dos subagentes persistentes ejecutándose en segundo plano: uno que busca constantemente mejoras en la arquitectura del código y otro que caza abstracciones duplicadas que deberían unificarse. Ambos abren pull requests como cualquier colaborador humano, y ninguno alcanza un punto de parada limpio porque el código sigue moviéndose bajo sus pies. Siguen adelante hasta que una señal les dice que el trabajo está terminado.

Y el 90% de lo que ves en producción no se acerca a eso.

---

El Problema: El Acoplamiento Frágil Entre Agentes

Cuando un solo LLM simula múltiples agentes, las instrucciones de un "agente" contaminan el contexto del siguiente. No es que los agentes se coordinen mal. Es que ni siquiera son agentes independientes. Son máscaras que se pone el mismo modelo en distintos momentos de la conversación, y las máscaras se filtran entre sí.

Pongamos un ejemplo real. Tienes un sistema con dos roles:

❌ Anti-patrón: Un solo LLM simulando agentes

¿El problema? Cuando el "investigador" termina su parte, el contexto que hereda el "editor" está lleno de instrucciones de análisis. El editor empieza a escribir en formato de viñetas. Se pone en modo "análisis" en lugar de "edición". Las instrucciones del agente anterior se filtran al siguiente.

Esto no es coordinación. *Es intoxicación contextual. *

El output final tiene artefactos lingüísticos del paso anterior. El formato cambia a mitad del texto. Instrucciones residuales aparecen como parte del contenido. Y lo peor: el sistema parece funcionar bien en las primeras iteraciones, pero la degradación es acumulativa. En pruebas con 10 ejecuciones secuenciales, el mismo prompt produce resultados cada vez más inconsistentes.

Y la mayoría de tutoriales ni siquiera mencionan que esto ocurre.

---

La Evidencia: Por Qué Más Agentes No Escala Linealmente

Cada agente adicional introduce ruido en el sistema. En un sistema con N agentes mal aislados, la probabilidad de degradación del output crece exponencialmente, no linealmente.

¿Por qué? Porque cada agente puede introducir:

Artefactos lingüísticos del formato anterior: si el agente previo trabajaba con viñetas, listas numeradas o JSON, el siguiente agente tiende a reproducir ese formato aunque no sea apropiado para su tarea.
Instrucciones residuales: fragmentos del system prompt o de instrucciones de agentes anteriores que el modelo interpreta como parte de su tarea actual.
Meta-información contaminante: detalles sobre agentes previos, su rendimiento, sus decisiones intermedias, que el siguiente agente confunde con información relevante para su trabajo.

El rendimiento real sigue una curva de rendimientos decrecientes que rápidamente se vuelve negativa. A partir de 3-4 agentes mal coordinados, el output es peor que con un solo agente. Es contra-intuitivo para quien piensa que "más agentes = más capacidad de procesamiento", pero es la realidad que muestran los sistemas en producción.

Cherny lo describió en su charla de @Scale: los subagentes que él ejecuta en segundo plano no comparten contexto. Cada uno tiene su propio objetivo, su propio contexto y su propia memoria. No se pasan mensajes entre sí. Reportan al supervisor, que decide qué hacer con cada output. Esta es la diferencia fundamental entre un sistema que escala y uno que se degrada.

El patrón que describió Cherny —el "loop"— es estructuralmente similar a una función recursiva tradicional, con una diferencia crítica: un bucle recursivo normal tiene una condición de terminación dura, mientras que un bucle agentivo no la tiene. Es un subagente quien decide cuándo el trabajo está terminado, no una regla hard-coded. Esto permite que el bucle se ejecute durante horas o incluso días, a través de miles de tokens, sin que una señal externa lo detenga.

La implementación abierta más popular de este patrón es el "Ralph Loop", que sigue una lógica deliberadamente simple: pide al modelo que resuma todo lo que ha hecho hasta ahora y luego pregunta si ha cumplido su objetivo. Si el modelo dice que sí, el bucle termina. Si dice que no, el bucle se ejecuta de nuevo con el nuevo contexto adjunto. El nombre, tomado del personaje Ralph Wiggum de Los Simpson, refleja la crudeza intencionada de la técnica, pero su efectividad ha hecho que sea adoptada por proyectos open-source en todo el ecosistema de codificación agentiva.

Los tests unitarios rara vez capturan esta degradación a largo plazo. En cadenas de 5+ interacciones, los artefactos se acumulan. Prueba tu sistema con 10 interacciones secuenciales y mide la coherencia del output final vs. la primera iteración.

*Verás la caída. *

---

El Patrón que Sí Funciona: Supervisor con Contextos Aislados

El patrón que realmente resuelve la coordinación multi-agente no es nuevo. Es el mismo principio que aprendimos con los microservicios: interfaces claras, contextos aislados, un orquestador que gestiona el flujo. La historia del desarrollo de software es, en gran parte, la historia de aprender a aislar responsabilidades. En los 90s aprendimos encapsulamiento con OOP. En los 2010s aprendimos contextos aislados con microservicios. Ahora estamos redescubriendo esas mismas lecciones en sistemas multi-agente.

Así es como se ve el patrón correcto:

✅ Patrón Supervisor con contextos aislados

¿Ves la diferencia? El supervisor transforma el output entre agentes. No lo pasa directamente. Cada agente recibe exactamente lo que necesita, en el formato que necesita. El supervisor no pasa el historial completo de la conversación. No pasa las instrucciones que recibió el agente anterior. Pasa únicamente el subconjunto de información relevante, mapeado al schema de entrada del siguiente agente.

Esto convierte un sistema frágilmente acoplado en uno con interfaces bien definidas. Es la misma lección que aprendimos cuando pasamos de monolitos a microservicios: el encapsulamiento no es opcional.

El supervisor además no necesita ser un LLM. Puede ser lógica condicional, un state machine, o un worker queue. Lo importante no es que el supervisor sea inteligente, sino que aisle. Que actúe como una barrera de aislamiento entre contextos, no como un mero pasador de mensajes.

---

El Marco de 5 Pasos para Multi-Agent Coordination Real

Aquí tienes El Patrón Supervisor con Contextos Aislados — el framework que uso en producción para sistemas multi-agente que realmente funcionan.

1. Audita tu sistema actual

Identifica si tus "agentes" comparten el mismo contexto de LLM. Si todos usan el mismo system prompt con instrucciones de rol, no tienes agentes. Tienes un solo LLM con máscaras.

Señal de alerta: Si puedes cambiar de "agente de investigación" a "agente de edición" simplemente cambiando el mensaje en el mismo hilo de chat, no tienes un sistema multi-agente.

Ejercicio práctico: Coge tu sistema actual y ejecuta 10 veces la misma tarea. Mide cuánto varía el output. Si ves cambios de formato, instrucciones residuales en el contenido, o artefactos de pasos anteriores, tu sistema está intoxicado. La variabilidad es síntoma de acoplamiento frágil.

2. Define interfaces estrictas entre agentes

Cada agente necesita un contrato claro de entrada/salida. Usa typed dicts, Pydantic models o dataclasses. El schema debe ser validable antes de pasar al siguiente agente.

Si no puedes validar el output de un agente antes de pasarlo al siguiente, no tienes interfaces. Tienes esperanza. La validación en tiempo de ejecución es lo único que te garantiza que el contrato se cumple. Si el agente investigador devuelve un campo que no está en su schema de salida, el supervisor debe rechazarlo o transformarlo antes de pasarlo al siguiente paso. No asumas que el LLM va a respetar el formato. Valídalo.

3. Implementa un router/orquestador central

No permitas que los agentes se comuniquen entre sí directamente. Todo pasa por un supervisor que decide:

Qué agente invoca
En qué orden
Cómo transforma los outputs entre agentes
Cuándo un agente debe reintentar si su output no supera validación
Cuándo el proceso completo ha terminado

Cherny lo llama "el loop": un supervisor que mantiene el estado global mientras cada subagente opera en su burbuja aislada. El supervisor no necesita ser un LLM. Puede ser lógica condicional, un state machine, o un worker queue. De hecho, cuanto más determinista sea el supervisor, menos riesgo de intoxicación contextual introduces en el propio orquestador.

4. Añade validación de contexto antes de cada paso

Antes de que un agente reciba input, verifica que el contexto no contenga:

Artefactos de formato de agentes anteriores
Instrucciones residuales
Meta-información de otros agentes
Contenido fuera del schema de entrada definido

Una técnica simple: ejecuta una función de limpieza que extrae solo los campos del schema de entrada y descarta todo lo demás. El agente recibe un contexto quirúrgicamente limpio. Otra técnica más robusta: serializa el output del agente anterior a JSON, validación mediante Pydantic, y luego construye el input del siguiente agente a partir de ese JSON validado, no del raw output del LLM. Así te aseguras de que cualquier artefacto que el LLM haya introducido fuera del schema se pierde en la serialización.

5. Mide la degradación por agente añadido

Establece métricas de calidad por cada agente que agregas. Si añadir un agente degrada la coherencia del output global, rediseña su interfaz o elimínalo.

La métrica más simple: pide al modelo que evalúe la coherencia del output final vs. el output sin ese agente. Si baja, el agente está introduciendo ruido, no valor.

Métricas adicionales que funcionan en producción:

Tasa de reintentos por agente: cuántas veces un agente necesita reintentar porque su output no supera la validación.
Desviación de formato: porcentaje de outputs que se desvían del schema esperado.
Coherencia secuencial: variación en la calidad del output final cuando se ejecuta el mismo pipeline 10 veces con el mismo input.
Ratio señal/ruido: proporción de tokens útiles en el output de cada agente frente a tokens irrelevantes o artefactos.

Estas métricas te darán visibilidad sobre dónde se está degradando tu sistema y qué agente está introduciendo más ruido.

---

El Acoplamiento Frágil es el Spaghetti Code de los AI Agents

En los 90s aprendimos que el encapsulamiento y las interfaces claras son fundamentales en OOP. En los 2010s aprendimos que los microservicios necesitan contextos aislados y contratos de API.

*Hoy estamos redescubriendo esas mismas lecciones en sistemas multi-agente. *

CrewAI, LangGraph y AutoGen están empezando a implementar estos patrones de aislamiento. Pero la mayoría de tutoriales omiten este aspecto crítico. Te enseñan a "conectar agentes" sin explicar por qué el contexto compartido es veneno. Sin mencionar que tres agentes mal coordinados producen peor output que uno solo bien diseñado.

El resultado es la misma deuda técnica que vimos en los monolitos de los 2000s, pero con LLMs. En aquella época, el problema era que todo el código vivía en el mismo espacio de nombres, las mismas variables globales, el mismo ciclo de vida. Cambiar una parte del sistema podía romper cualquier otra parte. Hoy, el mismo patrón se reproduce con agentes: comparten el mismo contexto de conversación, las mismas instrucciones de sistema, los mismos historiales. Y el resultado es igual de frágil.

Cherny lo resumió en @Scale: "Los agentes no están esperando el siguiente prompt. Están esperando una señal de que el trabajo está terminado."

Esa señal no llega si el contexto está intoxicado. No llega si los agentes compiten por el mismo espacio de memoria. No llega si no hay un supervisor que transforme, valide y aísle.

Los principios clave que recordar:

Más agentes sin aislamiento = más ruido, no más especialización
El supervisor no solo decide qué agente invoca — actúa como barrera de aislamiento
Cada agente debe recibir únicamente el subconjunto del contexto que necesita
Valida el output de cada agente antes de pasarlo al siguiente
Si tu sistema multi-agente cabe en un solo archivo de Python y todos los agentes comparten el mismo hilo de conversación, probablemente no es multi-agente

La industria está avanzando hacia patrones más sólidos. El Ralph Loop, los subagentes persistentes de Cherny, los state machines con contextos aislados... todas son respuestas al mismo problema fundamental: los LLMs no están diseñados para compartir contexto limpio entre sí. Ignorar esa limitación técnica no la hace desaparecer.

*El 90% de los sistemas multi-agente no son multi-agente. * Ahora sabes cómo construir el 10% que sí lo es. La decisión es tuya: seguir añadiendo agentes al mismo contexto compartido y esperar resultados diferentes, o aplicar los principios de aislamiento que la ingeniería de software lleva décadas enseñándonos.