Los agentes LLM son sistemas distribuidos

La comunidad de IA está construyendo sistemas multiagente: equipos de LLM que se reparten el trabajo, se comunican y colaboran para resolver problemas que ningún modelo por sí solo podría abordar. Un agente "investigador" recopila información, un agente "programador" escribe la implementación, un agente "revisor" comprueba la calidad y un agente "coordinador" gestiona el flujo de trabajo. La propuesta es atractiva: agentes especializados colaborando como un buen equipo de ingeniería.

Si esto te suena conocido, no es casualidad. Los investigadores de sistemas distribuidos llevan 40 años estudiando cómo coordinar procesos independientes. Los sistemas multiagente con LLM están redescubriendo, desde cero, problemas que la comunidad de sistemas distribuidos resolvió (o demostró que no tienen solución) hace décadas. Entender estos paralelismos te ahorra reinventar soluciones y te evita construir sistemas que fallan de formas predecibles y bien conocidas.

El impuesto de la coordinación

La primera lección de los sistemas distribuidos: la coordinación tiene un coste. Dos procesos que trabajan por separado en tareas distintas son el doble de rápidos que uno. Dos procesos que trabajan en la misma tarea y necesitan coordinarse suelen ser más lentos que uno solo, porque el coste de comunicación y sincronización supera el beneficio del paralelismo.

Los sistemas multiagente con LLM lo sufren desde el primer momento. Un agente "investigador" produce un informe. El agente "programador" necesita entender ese informe para escribir código. El agente "revisor" necesita entender tanto el informe como el código para dar feedback útil. Cada traspaso obliga a serializar el contexto en un prompt, que el agente receptor tiene que interpretar y comprender. Es exactamente el problema de estado compartido de los sistemas distribuidos, y empeora a medida que añades agentes.

Single agent vs. multi-agent for a coding task:
Single agent:
1. Understand the problem         (1 LLM call)
2. Research relevant APIs          (2 LLM calls)
3. Write implementation            (1 LLM call)
4. Review and fix                  (1 LLM call)
Total: 5 LLM calls, full context throughout
Multi-agent (researcher + coder + reviewer):
1. Coordinator describes task      (1 LLM call)
2. Researcher reads and plans      (1 LLM call)
3. Researcher does research        (3 LLM calls)
4. Researcher summarizes findings  (1 LLM call)
5. Coder reads summary             (1 LLM call)  ← context lost here
6. Coder writes implementation     (1 LLM call)
7. Reviewer reads code + summary   (1 LLM call)  ← context lost here
8. Reviewer provides feedback      (1 LLM call)
9. Coordinator synthesizes         (1 LLM call)
Total: 11 LLM calls, context degraded at each handoff
More agents = more communication = more cost = worse context.

En sistemas distribuidos, esto es la Ley de Amdahl aplicada a la comunicación: la aceleración que aporta el paralelismo está limitada por la comunicación secuencial que no se puede paralelizar. Añadir más agentes a una tarea que requiere una coordinación estrecha hace que el sistema vaya más lento, no más rápido.

El problema del consenso

Cuando varios agentes trabajan en la misma tarea, necesitan ponerse de acuerdo en varias cosas. ¿Cuáles son los requisitos? ¿Qué enfoque seguimos? ¿Es correcta esta implementación? En sistemas distribuidos, esto es el problema del consenso, y es demostrablemente difícil: el resultado de imposibilidad FLP muestra que el consenso determinista es imposible en un sistema asíncrono con aunque sea un solo proceso defectuoso.

Los agentes LLM son peores que los procesos distribuidos tradicionales para alcanzar consenso porque no son deterministas. Haz la misma pregunta al mismo agente dos veces y puede que obtengas respuestas distintas. Dos agentes revisando el mismo código pueden discrepar sobre si es correcto. Un agente "coordinador" al que le pides que resuelva la discrepancia podría acabar tirando una moneda.

Los frameworks multiagente suelen resolver esto designando un agente coordinador con la autoridad final (un modelo de consenso centralizado: simple, pero crea un punto único de fallo) o recurriendo a votación por mayoría (caro, porque necesitas al menos tres agentes por decisión). Ambos enfoques funcionan, pero están resolviendo un problema que solo existe porque repartiste el trabajo entre varios agentes en primer lugar.

Fallos que deberían sonarte

Los sistemas multiagente fallan de formas que los ingenieros de sistemas distribuidos reconocerán al instante.

• Fallos en cascada. El agente A produce una salida defectuosa. El agente B, partiendo de la salida de A, genera una peor. El agente C, revisando el trabajo de B, no detecta el error original porque heredó las suposiciones equivocadas. Es el equivalente en sistemas distribuidos a la propagación de errores: basura entra, basura sale, amplificada en cada etapa.
• Deadlocks. El agente A espera la salida del agente B para avanzar. El agente B espera el feedback del agente A para avanzar. Ninguno puede progresar. En la práctica, se manifiesta como bucles infinitos en los que los agentes se pasan el trabajo de un lado a otro sin converger.
• Split brain. Dos agentes que trabajan en tareas relacionadas desarrollan visiones inconsistentes del problema. Uno asume que la API devuelve JSON; el otro, que devuelve XML. Sus salidas son individualmente correctas, pero mutuamente incompatibles.
• Thundering herd. Un agente coordinador envía trabajo a varios agentes a la vez. Todos golpean la misma API, agotan el mismo límite de tasa o intentan modificar el mismo archivo. Contención de recursos que un único agente nunca encontraría.

Cuándo los sistemas multiagente sí ayudan

El paralelismo con los sistemas distribuidos funciona en ambos sentidos. Los sistemas distribuidos tienen beneficios reales para problemas concretos, y los sistemas multiagente también, cuando se usan en problemas que de verdad se benefician de la descomposición.

Tareas vergonzosamente paralelas. Si necesitas analizar 50 codebases buscando el mismo patrón, 50 agentes trabajando de forma independiente son realmente 50 veces más rápidos. No hace falta coordinación: cada agente trabaja con una entrada separada y produce una salida independiente. Es el patrón MapReduce, y funciona tan bien con agentes LLM como con el procesamiento distribuido de datos.

Perspectivas diversas. Pedirle a tres agentes con prompts de sistema distintos que revisen el mismo código puede sacar a la luz problemas que una única revisión pasaría por alto. Es el patrón de redundancia, como tener varios revisores en un PR. El coste es tres veces más cómputo, pero la cobertura es más amplia.

Especialización con interfaces limpias. Un agente de traducción que recibe texto y devuelve texto traducido tiene una interfaz limpia. Lo mismo ocurre con un agente de resumen que recibe un documento y devuelve un resumen. Encadenarlos (traducir y luego resumir) funciona bien porque la interfaz entre ambos es sencilla. El equivalente en sistemas distribuidos: los microservicios con APIs bien definidas funcionan mejor que los microservicios con interfaces complejas y muy habladoras.

Lecciones de los sistemas distribuidos

Si estás construyendo sistemas multiagente con LLM, décadas de sabiduría en sistemas distribuidos se aplican directamente.

1. Prefiere menos agentes, pero más capaces, a muchos especializados. Igual que un monolito bien diseñado supera a una arquitectura de microservicios mal diseñada, un único agente capaz con un buen prompting supera a un equipo de agentes estrechos en la mayoría de las tareas. Añade agentes solo cuando hayas demostrado que un único agente no puede con la carga de trabajo.
2. Define interfaces claras entre agentes. La entrada y la salida de cada agente deben estar bien definidas. Los traspasos vagos ("averigua lo que encontró el investigador e impleméntalo") provocan pérdida de contexto y malas interpretaciones. Los contratos de datos estructurados entre agentes funcionan mejor que el texto libre.
3. Haz que los agentes sean idempotentes. Si un agente falla a mitad de camino, debería poder reiniciarse con la misma entrada y obtener un resultado correcto. Esto exige agentes sin estado oculto y sin efectos secundarios hasta que hayan confirmado que su salida es correcta.
4. Añade observabilidad. Registra cada mensaje entre agentes, cada decisión y cada fallo. Cuando un sistema multiagente produce una salida incorrecta, necesitas rastrear el error hasta el agente que tomó la decisión equivocada y averiguar por qué. Sin observabilidad, depurar es adivinar.
5. Diseña para fallos parciales. Cualquier agente puede fallar, producir basura o agotar el tiempo de espera. El sistema debe gestionarlo con elegancia: reintentar, recurrir a un enfoque más simple o pedir intervención humana. Nunca des por hecho que todos los agentes van a tener éxito.

La verdad incómoda

La mayoría de los sistemas multiagente con LLM funcionarían mejor como un único agente con un buen prompt. El sobrecoste de coordinación, la pérdida de contexto y los modos de fallo de las arquitecturas multiagente casi siempre superan a los beneficios en tareas que un solo modelo puede resolver. A medida que evolucionan las herramientas de IA, crece la tentación de construir sistemas multiagente elaborados, pero la lección de los sistemas distribuidos es clara: no distribuyas lo que no necesita ser distribuido.

Las excepciones son reales: tareas vergonzosamente paralelas, especialización genuina con interfaces limpias y problemas que superan la ventana de contexto de un único modelo. Para todo lo demás, un solo agente con un prompt bien estructurado, buenas herramientas y una estrategia de reintentos sensata superará a un equipo de agentes. Es menos emocionante desde el punto de vista arquitectónico, pero funciona mejor. El mejor sistema distribuido es el que no tuviste que construir.