Por qué más agentes de IA no siempre significa más resultados
Multi-Agent es probablemente el término más hypeado en el universo de la inteligencia artificial en 2025, y no es difícil entender por qué. La idea de tener varios agentes de IA trabajando juntos, cada uno encargándose de una parte específica del problema, suena genial en la teoría. Y en algunos casos, realmente lo es. Klarna, por ejemplo, construyó una arquitectura multi-agent usando LangGraph que maneja 2,3 millones de conversaciones al mes — el equivalente al trabajo de 700 agentes humanos a tiempo completo. El tiempo de resolución bajó de 11 minutos a menos de 2, las consultas repetidas disminuyeron un 25%, la satisfacción del cliente subió un 47% y el costo por transacción de atención pasó de 0,32 dólares a 0,19 dólares. El ahorro total proyectado hasta finales de 2025 ronda los 60 millones de dólares. Ese tipo de resultado hace que cualquier líder de tecnología quiera replicar la estrategia de inmediato, pero la realidad es bastante más compleja de lo que parece a primera vista.
El balde de agua fría llega directo de Gartner, que prevé que más del 40% de los proyectos de IA agéntica serán cancelados para finales de 2027. No estamos hablando de proyectos pausados o reducidos en alcance — estamos hablando de cancelaciones definitivas, motivadas por costos fuera de control, valor de negocio difuso y controles de riesgo inadecuados. Misma tecnología. Mismo año. Resultados completamente opuestos. Esta estadística muestra que existe una diferencia enorme entre montar un prototipo divertido con tres agentes conversando entre sí y poner un sistema multi-agent en producción que realmente entregue valor consistente para el negocio.
El efecto cascada: cuando los errores se multiplican por 17 veces
En diciembre de 2025, un equipo de Google DeepMind liderado por Yubin Kim puso a prueba de forma rigurosa la premisa de que más agentes generan mejores resultados. Ejecutaron 180 configuraciones diferentes en 5 arquitecturas de agentes y 3 familias de LLMs (Large Language Models). El hallazgo debería estar pegado en el monitor de todo equipo de IA:
Las redes multi-agent sin estructura amplifican errores hasta 17,2 veces comparado con un único agente como baseline.
No es un 17% peor. Es diecisiete veces peor.
Cuando los agentes se juntan sin una topología definida — lo que el estudio llama bag of agents — la salida de cada agente se convierte en la entrada del siguiente. Los errores no se cancelan. Se acumulan en cascada. Imagina un pipeline donde el Agente 1 extrae la intención del cliente a partir de un ticket de soporte. Confunde una disputa de cobro con una simple consulta sobre facturación — una diferencia sutil, ¿verdad? El Agente 2 toma la plantilla de respuesta equivocada. El Agente 3 genera una respuesta que aborda el problema incorrecto. El Agente 4 la envía. El cliente responde irritado. El sistema procesa la respuesta irritada por la misma cadena rota. Cada loop amplifica la interpretación equivocada original. Ese es el efecto 17x en la práctica: no un fallo catastrófico y evidente, sino una acumulación silenciosa de pequeños errores que produce nonsense con apariencia de certeza.
El mismo estudio encontró un umbral de saturación: las ganancias de coordinación se estabilizan a partir de 4 agentes. Por debajo de ese número, agregar agentes a un sistema estructurado ayuda. Por encima de él, el overhead de coordinación consume los beneficios.
Este no es un hallazgo aislado. El estudio MAST (Multi-Agent Systems Failure Taxonomy), publicado en marzo de 2025, analizó 1.642 trazas de ejecución en 7 frameworks open-source. Las tasas de fallo variaron del 41% al 86,7%. La mayor categoría de fallo: quiebres de coordinación, responsables del 36,9% de todas las fallas registradas.
El problema de la fiabilidad compuesta
Esta es la matemática que la mayoría de los documentos de arquitectura simplemente ignora, y que puede definir el éxito o fracaso de tu proyecto.
Un único agente completa una etapa con un 99% de fiabilidad. Suena excelente, ¿verdad? Ahora encadena 10 etapas secuenciales: 0,99 elevado a 10 da como resultado un 90,4% de fiabilidad general. Todavía aceptable.
Pero si baja al 95% por etapa — lo cual sigue siendo un número fuerte para la mayoría de las tareas de IA — diez etapas resultan en apenas un 59,9% de fiabilidad total. ¿Veinte etapas? Un mero 35,8%.
Empezaste con agentes que aciertan 19 de cada 20 veces. Terminaste con un sistema que falla casi dos tercios de las veces. 😬
Los costos de tokens también se multiplican con esta lógica. Un workflow de análisis de documentos que consume 10.000 tokens con un único agente puede requerir 35.000 tokens en una implementación con 4 agentes. Eso representa un multiplicador de 3,5x en los costos antes siquiera de contabilizar reintentos, manejo de errores y mensajes de coordinación entre agentes.
Es por eso que la arquitectura de Klarna funciona y la mayoría de las copias no funcionan. La diferencia no es la cantidad de agentes. Es la topología — la forma en que los agentes están organizados y se comunican entre sí.
Tres patrones de arquitectura multi-agent que funcionan en producción
En lugar de preguntar cuántos agentes se necesitan, la pregunta más inteligente es: ¿cómo fallaría definitivamente al construir un sistema multi-agent? La investigación responde con claridad. Encadenando agentes sin estructura. Ignorando el overhead de coordinación. Tratando todo problema como un problema multi-agent cuando un único agente bien configurado bastaría.
Tres patrones evitan estos modos de fallo. Cada uno sirve para un formato diferente de tarea.
Plan-and-Execute (Planificar y Ejecutar)
Un modelo más capaz crea el plan completo. Modelos más baratos y rápidos ejecutan cada etapa. El planificador se encarga del razonamiento; los ejecutores se encargan de la acción.
Esto es esencialmente lo que Klarna ejecuta. Un modelo de frontera analiza la intención del cliente y mapea los pasos de resolución. Modelos más pequeños ejecutan cada paso: extraer datos de la cuenta, procesar reembolsos, generar respuestas. El modelo de planificación toca la tarea una sola vez. Los modelos de ejecución manejan el volumen. El impacto en costos es significativo: dirigir la planificación a un modelo capaz y la ejecución a modelos más baratos puede reducir costos hasta en un 90% comparado con usar modelos de frontera para todo.
Cuándo funciona: tareas con objetivos claros que se descomponen en etapas secuenciales. Procesamiento de documentos, workflows de atención al cliente, pipelines de investigación.
Cuándo falla: entornos que cambian durante la ejecución. Si el plan original se vuelve inválido a mitad de camino, necesitas checkpoints de replanificación o un patrón completamente diferente.
Supervisor-Worker (Supervisor y Trabajadores)
Un agente supervisor gestiona el enrutamiento y las decisiones. Agentes trabajadores manejan subtareas especializadas. El supervisor divide las solicitudes, delega, monitorea el progreso y consolida los resultados.
La investigación de Google DeepMind valida este patrón directamente. Un plano de control centralizado suprime la amplificación de errores 17x que las redes bag of agents producen. El supervisor actúa como punto único de coordinación, previniendo situaciones donde, por ejemplo, un agente de soporte aprueba un reembolso mientras un agente de compliance simultáneamente bloquea la misma solicitud.
Cuándo funciona: tareas heterogéneas que requieren diferentes especializaciones. Soporte al cliente con rutas de escalación, pipelines de contenido con etapas de revisión, análisis financiero combinando múltiples fuentes de datos.
Cuándo falla: cuando el supervisor se convierte en cuello de botella. Si toda decisión pasa por un único agente, recreaste el monolito del que intentabas escapar. La solución: dar a los trabajadores autonomía limitada para decisiones dentro de su dominio y escalar solo los casos extremos.
Swarm (Handoffs Descentralizados)
Sin supervisor. Los agentes se pasan la pelota unos a otros según el contexto. El Agente A se encarga del triaje, identifica que es un problema de facturación y transfiere al Agente B, especialista en facturación. El Agente B resuelve o transfiere al Agente C, de escalación, si es necesario.
El framework Swarm original de OpenAI era solo educativo — lo dejaron explícito en el README. El Agents SDK, versión de producción lanzada en marzo de 2025, implementa este patrón con guardrails: cada agente declara sus destinos de handoff y el framework garantiza que las transferencias sigan las rutas declaradas.
Cuándo funciona: workflows de alto volumen y bien definidos, donde la lógica de enrutamiento está integrada en la propia tarea. Soporte al cliente por chat, onboarding en múltiples etapas, sistemas de triaje.
Cuándo falla: grafos de handoff complejos. Sin un supervisor, depurar por qué el usuario terminó en el Agente F en vez del Agente D requiere herramientas de observabilidad de nivel de producción. Si no tienes tracing distribuido, no uses este patrón.
Qué framework multi-agent usar
Tres frameworks dominan los despliegues de sistemas multi-agent en producción en este momento. Cada uno refleja una filosofía diferente sobre cómo deben organizarse los agentes.
LangGraph utiliza máquinas de estado basadas en grafos. Con 34,5 millones de descargas mensuales, ofrece schemas de estado tipados que permiten checkpointing e inspección precisos. Es lo que Klarna ejecuta en producción. La mejor opción para workflows con estado donde necesitas intervención humana en el loop, lógica de ramificación y ejecución durable. La contrapartida: curva de aprendizaje más pronunciada que las alternativas.
CrewAI organiza agentes como equipos basados en roles. Con 44.300 estrellas en GitHub y creciendo, ofrece la menor barrera de entrada: define los roles de los agentes, asigna tareas y el framework se encarga de la coordinación. Despliega equipos aproximadamente un 40% más rápido que LangGraph para casos de uso simples. La contrapartida: soporte limitado para ciclos y gestión de estado complejo.
OpenAI Agents SDK proporciona primitivas ligeras — Agents, Handoffs y Guardrails. Es el único framework importante con soporte igual para Python y TypeScript/JavaScript. Abstracción limpia para el patrón Swarm. La contrapartida: acoplamiento más fuerte con los modelos de OpenAI.
Un protocolo que vale la pena conocer: el Model Context Protocol (MCP) se convirtió en el estándar de facto para interoperabilidad de herramientas de agentes. Anthropic donó el protocolo a la Linux Foundation en diciembre de 2025, cofundado por Anthropic, Block y OpenAI bajo la Agentic AI Foundation. Más de 10.000 servidores MCP públicos activos existen hoy. Los tres frameworks mencionados soportan el protocolo. Si estás evaluando herramientas, compatibilidad con MCP es requisito básico.
Si tienes dudas sobre por dónde empezar, la combinación de Plan-and-Execute con LangGraph es la más probada en batalla. Cubre la mayor variedad de casos de uso. Y cambiar de patrón después es una decisión reversible — no necesitas acertar a la primera.
Cinco modos de fallo que matan proyectos en producción
El estudio MAST identificó 14 modos de fallo en 3 categorías. Los cinco siguientes representan la mayoría de las fallas en producción. Cada uno incluye una medida de prevención específica que puede implementarse antes del próximo despliegue.
Deterioro de fiabilidad compuesta
Calcula la fiabilidad de extremo a extremo antes de pasar a producción. Multiplica las tasas de éxito por etapa a lo largo de toda la cadena. Si el número cae por debajo del 80%, reduce la longitud de la cadena o agrega checkpoints de verificación. La recomendación es mantener cadenas con menos de 5 etapas secuenciales. Inserta un agente de verificación en la etapa 3 y en la etapa 5 que valide la calidad del output antes de pasarlo adelante. Si la verificación falla, redirige a un humano o a una ruta alternativa — no a un reintento de la misma cadena.
Tasa de coordinación
Este modo de fallo es responsable del 36,9% de todas las fallas en sistemas multi-agent. Cuando dos agentes reciben instrucciones ambiguas, las interpretan de formas diferentes. Un agente de soporte aprueba un reembolso mientras un agente de compliance lo bloquea. El usuario recibe señales contradictorias. La prevención exige contratos explícitos de entrada y salida entre cada par de agentes. Define el schema de datos en cada frontera y valida. Nada de estado compartido implícito. Si la salida del Agente A alimenta al Agente B, ambos necesitan concordar con el formato antes del despliegue, no en tiempo de ejecución.
Explosión de costos
Los costos de tokens se multiplican entre agentes — 3,5x en casos documentados. Los loops de reintento pueden quemar más de 40 dólares en tarifas de API en minutos, sin ningún output útil que mostrar. La prevención incluye definir presupuestos rígidos de tokens por agente y por workflow. Implementa circuit breakers: si un agente excede su presupuesto, interrumpe el workflow y muestra un error en lugar de seguir reintentando. Registra el costo por workflow completado para identificar regresiones a tiempo.
Brechas de seguridad
El OWASP Top 10 para Aplicaciones LLM encontró vulnerabilidades de prompt injection en el 73% de los despliegues de producción evaluados. En sistemas multi-agent, un agente comprometido puede propagar instrucciones maliciosas a todos los agentes aguas abajo. La prevención exige sanitización de input en cada frontera entre agentes, no solo en el punto de entrada. Trata los mensajes entre agentes con la misma desconfianza que aplicarías a input de usuario externo. Ejecuta un ejercicio de red team contra tu cadena de agentes antes del lanzamiento en producción.
Loops infinitos de reintento
El Agente A falla. Reintenta. Falla de nuevo. En sistemas multi-agent, la falla del Agente A activa el manejo de errores del Agente B, que llama al Agente A de nuevo. El loop se ejecuta hasta que el presupuesto se agota. La prevención: máximo de 3 reintentos por agente por ejecución de workflow. Backoff exponencial entre reintentos. Colas de dead-letter para tareas que fallan más allá del límite de reintentos. Y una regla absoluta: nunca permitas que un agente active a otro sin una verificación de ciclo en la capa de orquestación.
Herramienta versus trabajador: la diferencia de 60 millones de dólares
En febrero de 2026, el National Bureau of Economic Research (NBER) publicó un estudio encuestando a casi 6.000 ejecutivos en Estados Unidos, Reino Unido, Alemania y Australia. El hallazgo: el 89% de las empresas no registró ningún cambio en la productividad con IA. El 90% de los gestores dijo que la IA no tuvo impacto en el empleo. Estas empresas usaban IA en promedio 1,5 horas por semana por ejecutivo.
Fortune lo llamó una resurrección de la paradoja de Robert Solow de 1987: ves la era de las computadoras en todas partes, menos en las estadísticas de productividad. La historia repitiéndose cuarenta años después con una tecnología diferente y el mismo patrón.
El 90% que no vio impacto implementó IA como herramienta. Las empresas que ahorraron millones implementaron IA como trabajadores.
El contraste con Klarna no se trata de mejores modelos o más poder computacional. Es una elección estructural. El 90% trató la IA como copiloto — una herramienta que asiste a un humano en el loop, usada 1,5 horas por semana. Las empresas con retornos reales, como Klarna, Ramp y Reddit vía Salesforce Agentforce, trataron la IA como fuerza de trabajo: agentes autónomos ejecutando workflows estructurados con supervisión humana en los puntos de decisión, no en cada etapa.
Esto no es una brecha tecnológica. Es una brecha de arquitectura. El costo de oportunidad es impresionante: el mismo presupuesto de ingeniería produciendo cero ROI de un lado versus 60 millones en ahorro del otro. La variable no es cuánto gastas. Es cómo estructuras.
Cómo elegir el camino correcto para tu escenario
La decisión entre usar un agente único o una arquitectura multi-agent no debería estar guiada por el hype, sino por criterios técnicos y de negocio bien definidos. Pregúntate primero si el problema que intentas resolver requiere múltiples especialidades distintas que no pueden combinarse en un único prompt o contexto. Si la respuesta es no, empieza simple.
Pregúntate también cuál es el presupuesto aceptable de costos operativos por solicitud y cuál es la latencia máxima tolerable por el usuario final. Cada agente adicional en el sistema aumenta ambos indicadores. Sin claridad sobre estos límites desde el inicio, el proyecto corre un serio riesgo de convertirse en uno más en la estadística del 40% de Gartner.
Invierte en observabilidad desde el día cero. Antes de escribir el primer agente, define cómo vas a monitorear cada llamada al modelo de lenguaje, cada intercambio de mensajes entre agentes y cada decisión de enrutamiento. Herramientas como LangSmith y plataformas de tracing distribuido crean la capa de visibilidad que es esencial para identificar errores, optimizar rendimiento y controlar costos en producción. Sin esto, estás pilotando a oscuras — puede funcionar por un tiempo, pero cuando llegue la turbulencia, y va a llegar, no vas a tener instrumentos para navegar. 🧭
Adopta una mentalidad de evolución gradual. Empieza con el mínimo de agentes necesarios, mide resultados reales — no solo métricas técnicas, sino impacto en el negocio — y agrega complejidad solo cuando los datos lo justifiquen.
El 40% de los proyectos de IA agéntica serán cancelados para 2027. El otro 60% llegará a producción. La diferencia no va a ser qué LLM eligieron o cuánto gastaron en computación. Va a ser si entendieron los patrones de arquitectura correctos, hicieron las cuentas de fiabilidad compuesta y construyeron sus sistemas para sobrevivir a los modos de fallo que derriban todo lo demás.
Klarna no desplegó 700 agentes para reemplazar a 700 humanos. Construyó un sistema multi-agent estructurado donde un planificador inteligente enruta trabajo hacia ejecutores baratos, donde cada handoff tiene un contrato explícito y donde la arquitectura fue diseñada para fallar de forma controlada en lugar de entrar en cascada. Los mismos patrones, los mismos frameworks y los mismos datos de fallo están disponibles para cualquier equipo. Lo que construyas con eso es la única variable que queda. 🎯
