Sistemas multi-agente: cuándo tienen sentido y cuándo no

Una fintech con la que trabajé hace un tiempo había gastado más de 150k en un chatbot de atención al cliente. Llevaban meses iterando. El bot funcionaba bien en demos, pero en producción inventaba políticas de devolución que no existían y daba precios incorrectos. No siempre, quizás un 25-30% de las veces, pero suficiente para que el equipo de soporte odiara la herramienta.

El modelo no era el problema. Usaban uno de los modelos punteros del momento, bien configurado. El problema era que un solo agente intentaba hacer demasiadas cosas: consultar catálogo, verificar stock, calcular precios con descuentos, gestionar devoluciones, y responder dudas generales. Demasiado contexto, demasiadas instrucciones contradictorias.

La solución que propuse fue dividir el trabajo. En lugar de un bot que lo supiera todo, cinco agentes más pequeños que supieran mucho de poco. Uno para catálogo, otro para pricing, otro para logística, otro para devoluciones, y un orquestador que decidiera a quién preguntar. Los errores bajaron bastante, aunque no tengo un número exacto porque la métrica cambió a mitad del proyecto.

Qué es un sistema multi-agente (sin buzzwords)

Piensa en un hospital. No hay un médico que haga todo. Hay especialistas: cardiólogos, radiólogos, cirujanos. Y hay triaje, que decide a quién enviar cada paciente.

Un sistema multi-agente funciona parecido. En lugar de un LLM gigante con un prompt enorme, tienes agentes especializados que dominan tareas concretas. Y algo que coordina quién hace qué.

Los componentes típicos:

Orquestador: Recibe la petición, decide qué agente o agentes necesitan actuar, y combina los resultados. No hace el trabajo real, solo dirige tráfico.

Agentes especializados: Cada uno tiene su propio prompt, sus propias herramientas, acceso a datos específicos. El agente de inventario sabe consultar la base de stock. El de precios tiene acceso a la API de pricing. Cada uno es experto en su dominio.

Memoria compartida: Un sitio donde los agentes dejan información para otros. El agente de catálogo encuentra el producto, el de precios añade el coste, el de envío calcula la entrega. No se hablan directamente, pero comparten contexto.

Herramientas: Funciones que los agentes pueden ejecutar. Llamar APIs, consultar bases de datos, enviar emails. Sin herramientas, un agente es solo un generador de texto.

Cuándo NO usar multi-agentes

Esto es lo que nadie te cuenta: la investigación reciente sugiere que en muchos casos un solo agente bien configurado supera a sistemas multi-agente.

Un estudio de 2025 encontró que en entornos con más de 10 herramientas, los sistemas multi-agente sufren una penalización de eficiencia de entre 2x y 6x comparado con agentes individuales. Eso es bastante.

Los de Cognition, los que crearon Devin, lo dicen claro: en 2025, ejecutar múltiples agentes en colaboración resulta en sistemas frágiles. Su recomendación es empezar con un agente lineal donde el contexto sea continuo.

No uses multi-agentes cuando:

La tarea se puede resolver en un solo paso lógico. Resumir documentos, clasificar tickets, extraer datos de facturas. Un solo agente bien configurado con buen RAG es suficiente.

Tienes muchas herramientas. Contraintuitivo, pero cierto. Con más de 10 herramientas, la coordinación entre agentes añade overhead que no compensa.

Tu agente individual ya funciona razonablemente bien. Hay investigación que sugiere que si tu agente único supera el 45% de accuracy en la tarea, añadir más agentes probablemente no mejore las cosas. A veces las empeora.

Las tareas son principalmente de escritura. Las operaciones de lectura se paralelizan bien. Las de escritura crean problemas de coordinación.

Eres un equipo pequeño. Multi-agentes requiere monitorización, debugging distribuido, tests de integración. Si sois dos personas, empieza simple.

Cuándo SÍ tiene sentido

Sí tiene sentido cuando:

El problema cruza varios dominios con reglas diferentes. Un asistente de e-commerce que gestiona catálogo, pagos, envíos y devoluciones. Cada área tiene su propia lógica, sus propios datos, sus propias excepciones.

Las tareas tienen dependencias claras y pases múltiples. Primero buscar producto, luego verificar stock, luego aplicar descuentos, luego calcular envío. Cuando el orden importa y cada paso necesita información del anterior.

Necesitas auditoría estricta. En banca, seguros, o cualquier sitio regulado, saber exactamente qué decisión tomó quién es obligatorio. Con multi-agentes puedes tracear cada paso.

Equipos diferentes mantienen partes diferentes. Si el equipo de pricing cambia sus reglas cada semana y el de logística cada mes, que cada uno tenga su agente facilita que iteren sin romperse mutuamente.

Los números reales de latencia (y la complejidad que nadie te cuenta)

Esto es más complicado de lo que parece. La latencia viene de muchos sitios, no solo de la generación del modelo.

Infraestructura del LLM:

Desde dónde llamas al modelo importa. Si tu servidor está en Europa y usas un endpoint en US, añades entre 80 y 150ms solo de red, en cada llamada. Y en multi-agente haces muchas llamadas. He visto sistemas donde el 30% de la latencia total era solo round-trips transatlánticos.

La propia infraestructura del proveedor añade variabilidad. En horas pico puedes pasar de 200ms de tiempo hasta el primer token a 800ms o más. Esto multiplica en multi-agente.

Gestión de contexto:

Cada agente necesita contexto. Cómo lo comprimes, cuánto mantienes, cómo lo pasas entre agentes, todo suma. He visto sistemas donde la serialización y deserialización del estado entre agentes añadía 50-100ms por salto.

Si usas memoria compartida con persistencia, añade latencia de base de datos. Si usas cache, tienes que gestionar invalidación. Si comprimes conversaciones para no pasarte de tokens, esa compresión tiene coste.

Comunicación entre agentes:

Si los agentes se pasan mensajes, cada paso de comunicación tiene overhead. Parsing de respuestas, validación de formato, manejo de errores, reintentos. En un sistema de 5 agentes con orquestador, fácilmente tienes 8-10 llamadas entre componentes por cada request del usuario.

Los números que veo en producción:

Sumando: un request simple a través de 3 agentes puede tardar 8-15 segundos fácilmente. Un request complejo con 5 agentes y múltiples pasadas, 30 segundos o más.

Si necesitas respuestas en menos de 2 segundos, la arquitectura multi-agente probablemente no sea para ti. Y si crees que puedes optimizarlo después, piénsalo dos veces. La complejidad crece exponencialmente con cada agente que añades.

Cómo lo implemento yo

No uso frameworks. Anthropic lo dice bien en su documentación: las implementaciones más exitosas no usan frameworks complejos ni librerías especializadas. Construyen con patrones simples y componibles.

Los frameworks añaden abstracción. La abstracción esconde lo que pasa. En producción necesitas ver exactamente qué está llegando a la API. Más código que escribir, sí, pero muchísimo más fácil de debuggear.

El patrón básico es un orquestador con routing:

El orquestador es otra llamada al LLM con un prompt específico para clasificar y routear. Cada agente es su propia llamada con su propio system prompt y herramientas. La memoria compartida suele ser un diccionario o store que pasas entre llamadas.

No es magia. Es ingeniería de software básica aplicada a llamadas de API. El trabajo real está en diseñar buenos prompts, definir herramientas claras, y sobre todo en el manejo de errores y la observabilidad.

Evaluaciones: esto no es testing tradicional

Aquí es donde la mayoría se pierde. Piensas que puedes testear un sistema multi-agente como testeas software tradicional. Tests unitarios, tests de integración, end-to-end. No funciona así.

Con LLMs no tienes determinismo. La misma entrada puede dar salidas diferentes. Un test que pasa hoy puede fallar mañana sin que hayas cambiado nada. Y cuando tienes múltiples agentes, la variabilidad se multiplica.

Lo que necesitas son evals, no tests.

Las evals son evaluaciones continuas sobre datasets representativos. No verifican que la salida sea exactamente X, verifican que la salida sea "suficientemente buena" según criterios definidos. Accuracy, relevancia, ausencia de alucinaciones, formato correcto, tono adecuado.

Por qué es más complejo que testing tradicional:

En software clásico, un test falla o pasa. Con LLMs tienes gradientes. Una respuesta puede ser 80% correcta. O correcta pero mal formateada. O correcta pero con tono inadecuado. Definir qué es "suficientemente bueno" es un problema en sí mismo.

En multi-agente se complica más. Si el resultado final es malo, ¿qué agente falló? ¿El orquestador routeó mal? ¿Un agente intermedio corrompió el contexto? ¿La combinación de respuestas perdió información? Necesitas evals a nivel de cada agente y a nivel de sistema.

Lo que hago en producción:

Datasets de evaluación por agente. Mínimo 50-100 casos representativos por agente, con salidas esperadas o criterios de evaluación.

Evals automáticas en CI. Cada cambio de prompt dispara evaluación contra el dataset. Si la accuracy baja del umbral, no se despliega.

LLM-as-judge para casos complejos. Usar otro modelo para evaluar si la respuesta es correcta cuando no hay una respuesta "exacta". Tiene sus problemas, pero escala mejor que revisión humana.

Monitorización continua en producción. Las evals no terminan en deploy. Muestreo de requests reales, evaluación offline, alertas cuando las métricas se degradan.

El coste que nadie menciona:

Construir un buen sistema de evals puede llevar más tiempo que construir el sistema multi-agente en sí. He visto proyectos donde el 40% del esfuerzo fue en evaluación y observabilidad. Pero sin eso, no sabes si tu sistema funciona. Solo esperas que funcione.

Errores que veo repetirse

Empezar con demasiados agentes. La tentación es modelar toda la organización desde el día uno. Empieza con dos, máximo tres. Añade cuando tengas un problema real que resolver, no antes.

No definir contratos. Cada agente necesita especificación clara: qué recibe, qué devuelve, cuándo falla. Sin esto, cuando algo se rompe, el debugging es imposible.

Ignorar observabilidad. Un sistema multi-agente sin logs estructurados y tracing es una caja negra. Necesitas poder reconstruir qué pasó cuando algo falla.

Subestimar costes. Cada agente es otra llamada al LLM. He visto facturas duplicarse o triplicarse después de migrar a multi-agente. Presupuesta desde el principio.

Depender de frameworks. Cuando el framework se actualiza, o deja de mantenerse, o tiene un bug en producción, estás atrapado. Con código propio sobre la API, tienes control total.

Sobre-ingeniería. Los modelos mejoran rápido. Lo que hoy necesita tres agentes, en seis meses quizás lo haga uno solo. No construyas para problemas que no tienes todavía.

El siguiente paso

Si tienes procesos que hoy dependen de humanos haciendo trabajo repetitivo con múltiples sistemas, los sistemas multi-agente pueden ayudar. No son magia. Son ingeniería de software aplicada a LLMs, con sus tradeoffs.

Mi recomendación: empieza con un solo agente bien hecho. Mide dónde falla. Solo cuando tengas datos claros de que la arquitectura simple no escala, considera partir en múltiples agentes.

Si quieres que revise tu caso, escríbeme. Como parte de mis servicios de consultoría, puedo darte una idea de si tiene sentido para tu situación y por dónde empezar. Puedes saber más sobre mi experiencia diseñando estos sistemas para empresas.