El desarrollo de software multi-agente es, en esencia, un problema de sistemas distribuidos: cuando varios modelos de lenguaje trabajan simultáneamente sin control central, se topan con los mismos desafíos que arrastran los sistemas distribuidos desde hace 50 años —coordinación sin punto único de sincronización, conflictos de estado, comunicación asíncrona, latencia impredecible. Y no, esperar mejores modelos no resuelve esto: los problemas son estructurales, no cognitivos.
En 30 segundos
- Un sistema multi-agente coordina múltiples LLMs en paralelo para tareas complejas, pero sin control central enfrenta los mismos problemas que cualquier sistema distribuido.
- Lenguajes formales como las coreografías (basadas en teoría de juegos) emergem como herramientas para describir interacciones entre agentes sin romper todo en el intento.
- Frameworks como CrewAI (role-based), AutoGen (conversacional) y LangGraph (graph-based) ofrecen abstracciones, pero la realidad sigue siendo: coordinación = fricción.
- Los desafíos prácticos (comunicación asíncrona, conflictos de estado, sincronización) no desaparecen con modelos más inteligentes; necesitán protocolos estándar como Model Context Protocol (MCP).
Desarrollo multi-agente en sistemas de IA es la arquitectura donde múltiples agentes (modelos de lenguaje o sistemas autónomos) trabajan juntos para resolver un problema, cada uno especializándose en un rol o subtarea. No es un solo LLM haciendo todo; son varios, coordinándose, delegando, compartiendo información.
Desarrollo multi-agente: qué es y por qué importa
Imaginá que necesitás analizar un paper técnico, sintetizar sus hallazgos, contrastarlos con datos públicos de la competencia, armar una estrategia de marketing, y documentar todo en un plan de 50 páginas. Un LLM solo se pierde, hace saltos lógicos raros, o te devuelve algo genérico. Pero si delegás: un agente que lee y estructura el paper, otro que busca benchmarks, otro que redacta la estrategia, otro que integra todo — súbitamente el resultado tiene profundidad.
Eso es multi-agente. No es un lujo; en problemas de verdad, es casi obligatorio.
Por qué importa: análisis complejo en paralelo, especialización por rol, capacidad de manejar tareas secuenciales sin perder contexto, reducción de alucinaciones por división de trabajo. Los casos de uso van desde investigación hasta orquestación de flujos empresariales.
El dilema fundamental: por qué es un problema de sistemas distribuidos
Acá es donde muchos se equivocan. No es un problema de “los LLMs no son lo suficientemente inteligentes”. Es un problema de arquitectura.
Cuando coordinás múltiples agentes sin un orquestador central, te enfrentás a: ¿cómo sincronizas el estado? ¿qué pasa si dos agentes dan respuestas contradictorias? ¿cómo resolvés conflictos si uno retarda la respuesta? ¿quién se encarga de manejar fallos parciales?
Según Kiran Codes, investigador en formalismos para sistemas multi-LLM, esto no es nuevo. Los sistemas distribuidos llevan 50 años lidiando con exactamente esto. Redes de computadoras, bases de datos replicadas, consenso en blockchain — todos resuelven coordinación sin punto central. La diferencia es que ahora el “nodo” es un LLM, pero el problema es idéntico. Lo explicamos a fondo en las capacidades del nuevo Claude Sonnet.
La coordinación sin control central es característica de sistemas distribuidos. Y heredamos todos los problemas que conlleva.
El mito de “esperar a mejores modelos”
Escuchás mucho esto: “Para que los sistemas multi-agente funcionen, necesitamos AGI. Cuando tengamos modelos más inteligentes, los agentes se coordinarán solos.”
Falso.
Es un razonamiento que suena lógico pero ignora la realidad. El argumento es: modelos actuales no son lo suficientemente smart → los problemas de coordinación vienen de falta de capacidad → modelos futuros + inteligentes = sin problemas de coordinación.
Pero los problemas de coordinación son estructurales, no cognitivos. Si tenés un sistema distribuido donde dos procesos escriben en la misma variable de forma asíncrona, un procesador más rápido no lo resuelve. Necesitás un protocolo de sincronización. Punto.
Incluso un AGI perfecto que entienda 100% el contexto tiene que esperar respuestas, manejar timeouts, resolver conflictos cuando otro agente dice lo opuesto. Son problemas de ingeniería, no de inteligencia (ponele que vos sos infinitamente inteligente pero estás en una montaña sin señal: el problema no es tu iq, es la comunicación).
Lenguajes y formalismos para describir sistemas multi-agente
El trabajo de Codes y su equipo en formalizar interacciones entre agentes va por este camino: necesitamos lenguajes precisos para describir cómo los agentes se comunican, coordinan, resuelven conflictos.
Una herramienta que surge es las coreografías — un formalismo matemático que describe cómo múltiples participantes interactúan sin necesidad de un director central. Aplicada a agentes, una coreografía describe: agente A hace X, espera respuesta de B, luego C participa si se cumple condición Y. Es conciso, elegante, verificable. Te puede servir nuestra cobertura de qué LLM elegir para tus agentes.
Combinado con teoría de juegos (que modelá cómo los agentes compiten y cooperan), el formalismo se vuelve aún más poderoso: cada agente tiene incentivos, estrategias, posibles movidas. El resultado es una descripción del sistema que es tanto ejecutable como verificable.
¿El punto? No deberías escribir coordinación entre agentes ad-hoc o con prompts. Necesitás un lenguaje formal donde la correctitud sea verificable antes de ejecutar.
Patrones de arquitectura: centralizado vs descentralizado
Dos formas principales de organizar agentes:
Centralizado: Un orquestador central coordina todos los agentes. El flujo es: orquestador recibe tarea, delega a agentes especializados, espera respuestas, sintetiza. Ventajas: control determinístico, fácil debuggear, garantías de orden. Desventajas: el orquestador es cuello de botella, latencia se multiplica por cada salto.
Descentralizado: Los agentes se comunican directamente entre sí siguiendo un protocolo. El flujo es: agente A detecta que necesita input de B, lo contacta directo, sigue adelante. Ventajas: paralelismo real, menor latencia en tareas independientes. Desventajas: difícil de debuggear, conflictos de estado, necesitás consenso para decisiones críticas.
Benchmark (según papers de investigación en sistemas multi-agente): arquitectura centralizada gana 80% en latencia para tareas paralelizables (muchas subtareas independientes). Pero en tareas secuenciales complejas (donde cada paso depende del anterior), degrada entre 39% y 70% por overhead de sincronización.
La arquitectura correcta depende de tu problema. No hay un ganador absoluto.
Frameworks y herramientas para coordinación multi-agente
Si decidís construir un sistema multi-agente hoy, tenés opciones:
CrewAI
Framework basado en roles. Cada agente tiene un rol (“investigador”, “escritor”, “validador”), herramientas asignadas, y tareas específicas. El orquestador de CrewAI maneja el flujo. Es simplista pero funciona bien para prototipos. Punto fuerte: fácil armar un primer sistema multi-agente sin bocha de código. Punto débil: poco granular, difícil customizar coordinación.
Microsoft AutoGen
Conversacional. Los agentes se comunican entre sí por chat, y vos definís reglas de cuándo termina la conversación (ej: cuando llegan a acuerdo). Mucho control, muy flexible. GitHub: 38k+ stars. Punto fuerte: puedo ver exactamente qué negocia cada agente. Punto débil: si los agentes no llegan a acuerdo, se quedan en loop conversando eternamente (management de timeouts es crítico). Cubrimos ese tema en detalle en ejecutar modelos en tu infraestructura.
LangGraph
Graph-based. Definís el flujo como un grafo dirigido: nodos son agentes/funciones, aristas son transiciones condicionales. Máximo control, mas verbose. Punto fuerte: preciso, debuggeable, permite bifurcaciones complejas. Punto débil: requiere pensar el flujo completo de antemano, no es flexible si aparecen caminos inesperados.
También existen OpenRouter (que tiene APIs para encadenar LLMs), LangChain (con abstracciones de agentes, aunque cada vez menos enfocado en multi-agente), y soluciones custom con Model Context Protocol (MCP) — un protocolo estándar de Anthropic para que herramientas y LLMs se comuniquen.
Desafíos prácticos: comunicación, conflictos y sincronización
La teoría está bonita. La práctica:
Comunicación asíncrona: Agente A pregunta a B, pero B tarda 15 segundos en responder (porque está llamando a una API). ¿A espera bloqueado o sigue adelante sin la respuesta? Si espera, perdés paralelismo. Si no espera, corres riesgo de decisiones basadas en información incompleta. Solution: cola de mensajes + timeouts explícitos + fallback strategies.
Conflictos de estado: Agente A lee un valor de la base de datos, lo modifica, lo escribe. Agente B hace lo mismo en paralelo. Resultado: conflicto, inconsistencia. No es problema de inteligencia; es que no hay lock. Solution: transacciones, versionado optimista, o evitar que agentes escriban a la misma fuente de verdad.
Sincronización: Necesitás que A, B y C terminen antes de que D siga. ¿Cómo? Barrier synchronization: D espera hasta que todos señalen “listo”. Pero si uno falla… ¿timeout y sigo sin D? ¿Reintentar? Estas decisiones son del negocio, no del LLM.
El protocolo Model Context Protocol (MCP) de Anthropic empieza a estandarizar esto: define cómo herramientas y agentes intercambian mensajes, manejan errores, señalan disponibilidad. No resuelve coordinación, pero da estructura.
Tabla comparativa de frameworks
| Framework | Tipo | Curva aprendizaje | Flexibilidad | Mejor para | Peor para |
|---|---|---|---|---|---|
| CrewAI | Role-based | Baja | Media | Prototipado rápido | Lógica compleja de coordinación |
| AutoGen | Conversacional | Media | Alta | Negociación entre agentes | Flujos determinísticos |
| LangGraph | Graph-based | Media-Alta | Muy alta | Flujos precisos, debuggeable | Sistemas donde el flujo es emergente |
| OpenRouter + custom | Flexible | Alta | Máxima | Casos muy específicos | Equipo sin expertise |
Errores comunes al implementar sistemas multi-agente
Asumir que coordinación es gratis
Muchos builders ven “multi-agente” y piensan “solo encadeno prompts y problema resuelto”. Realidad: cada transición entre agentes es fricción. Latencia, incompatibilidad de formatos, agentes esperando a otros, fallos parciales. La coordinación es la parte más cara. Sobre eso hablamos en modelos especializados como Sora.
No manejar timeouts ni fallos parciales
Agente A espera indefinidamente respuesta de B que nunca llega (API caída, token exhausto, crash). Sistema entero se queda colgado. Necesitás: timeout explícito (máximo espero X segundos), retry logic, fallback (si B no responde, uso aproximación de A), y circuito breaker (si B falla 5 veces, no lo llamo más).
Confundir paralelismo con correctitud
Pensás: “Corro A y B en paralelo, económico”. Verdad, a menos que A y B interfieran (escriben a la misma tabla, compiten por recursos, etc.). Necesitás análisis de dependencias antes de paralelizar. No es problema de LLM; es de design.
Confirmado vs pendiente
Confirmado
- Los sistemas distribuidos tienen 50 años de soluciones: Paxos, Raft, eventual consistency, quorum-based decisions. Reutilizables directamente en coordinación de agentes.
- Model Context Protocol (MCP) existe y estandariza comunicación: Anthropic lo definió, es open-source. No resuelve coordinación, pero estructura el intercambio de mensajes.
- CrewAI, AutoGen y LangGraph están en producción: Cientos de proyectos los usan. No son juguetes; tienen issues, se mantienen, sirven.
- Coreografías como formalismo matemático son demostrables: Codes tiene work-in-progress con el equipo, basado en teoría de juegos. No está publicado yet, pero existe.
Pendiente / no confirmado
- Que un formalismo estándar de coordinación vaya a dominar: Todo indica que habrá múltiples, dependiendo del caso de uso. No hay “SQL de sistemas multi-agente” todavía.
- Que modelos más inteligentes resuelvan coordinación: Posible, pero no automático. Un LLM más inteligente sigue siendo un nodo distribuido; sigue teniendo los mismos problemas estructurales.
- Performance de sistemas centralizados vs descentralizados en escala: Benchmarks existen, pero son específicos de cada problema. Generalizaciones son arriesgadas.
- Cuándo MCP se convierte en estándar de facto: Hoy es promisorio, pero recién empieza. Puede que en 2-3 años sea obvious. Hoy es “observar”.
Preguntas Frecuentes
¿Cómo se comunican los agentes entre sí?
Depende del framework. En CrewAI, es orquestador central que passa mensajes. En AutoGen, es chat directo entre agentes (cada uno lee lo que escribió el otro). En LangGraph, es transiciones de nodo condicionales. A nivel de red: HTTP, gRPC, colas de mensajes (Kafka, RabbitMQ), o APIs compartidas. El formato típico es JSON.
¿Necesito un orquestador central?
No obligatoriamente, pero generalmente sí. Simplifica debugging, garantiza orden, evita deadlocks. La alternativa (agentes que se buscan entre sí, service discovery, etc.) es más compleja. A menos que tengas un caso very specific, centralizado es más mantenible.
¿Cuál es el máximo de agentes que puedo coordinar?
Depende. En centralizado, 50-100 agentes es razonable; después latencia explota (cada round trip suma). En descentralizado, escala mejor pero es mucho más difícil debuggear. Recomendación: empieza con 3-5 agentes, observa cómo degrada, escala según datos reales.
¿Qué pasa si un agente falla?
Depende de cómo lo diseñés. Timeout + fallback es lo mínimo: si agente A no responde en 10 segundos, usás aproximación de B o abortas el flujo. Retry logic: reintentar 3 veces con backoff exponencial. Circuito breaker: si falló 5 veces, deshabilitar temporalmente. En sistemas críticos, redundancia: dos agentes hacen lo mismo, comparan resultados.
¿Cómo evito que agentes den respuestas contradictorias?
Depende de gravedad. Para “el precio es 100” vs “el precio es 150”: validación de schemas (ambos devuelven número, rangos definidos). Para “sí” vs “no”: arbitrador (tercer agente que resuelve conflicto), o mejor: diseñar para que no conflictúen (especializar roles). En casos críticos, la única solución es sincronización explícita: agente A espera aprobación de B antes de proceder.
Conclusión
La coordinación de múltiples agentes es un problema de sistemas distribuidos. No es un problema de inteligencia; es un problema de ingeniería.
Esperar a mejores modelos no lo resuelve. Necesitás: lenguajes formales para describir coordinación (coreografías + teoría de juegos), patrones probados de arquitectura distribuida (centralizado vs descentralizado, según caso), frameworks que abstracen la fricción (CrewAI, AutoGen, LangGraph), y disciplina para manejar fallos, timeouts, conflictos de estado.
Si estás construyendo un sistema multi-agente hoy, andá a Model Context Protocol como estándar de comunicación, elegí framework según flexibilidad que necesitás (CrewAI si es simple/rápido, LangGraph si es complejo), y diseñá explícitamente para fallos. No es sexy, pero es lo que funciona.
El futuro de multi-agente no es “AGI se encarga”. Es “tenemos mejores lenguajes, herramientas, y comprensión de coordinación distribuida”. Ya está pasando, silenciosamente.
Fuentes
- Multi-agentic Software Development is a Distributed Systems Problem (AGI can’t save you from it) — Análisis de Kiran Codes sobre formalismos y coordinación de agentes
- CrewAI en GitHub — Framework role-based para sistemas multi-agente
- Guía de patrones de diseño de agentes IA — Microsoft Azure — Arquitecturas centralizadas y descentralizadas
- Towards a Science of Scaling Agent Systems — Google Research sobre escalabilidad de sistemas multi-agente
- ArXiv: Investigación en sistemas multi-agente — Papers sobre coordinación y escalabilidad