Los sistemas multiagente son el rincón con más bombo de la ingeniería de IA. Los diagramas con un "agente planificador", un "agente investigador", un "agente crítico" y un "agente redactor" hablando entre sí quedan impresionantes en las diapositivas. En producción, el panorama tiene más matices. Algunos diseños multiagente dan resultados que ningún agente individual puede igualar. Muchos otros son más lentos, más caros y menos fiables que un solo agente bien construido. Este artículo resume lo que han publicado los equipos que operan estos sistemas a escala y te da un marco para decidir.
Qué significa realmente "multiagente"
Un sistema multiagente es cualquier arquitectura en la que más de un bucle dirigido por un LLM trabaja en una tarea, cada uno con su propio contexto, sus instrucciones y posiblemente sus herramientas. Formas habituales:
- Orquestador-subagentes: un agente principal planifica, lanza subagentes para las subtareas y sintetiza sus resultados. Los subagentes normalmente no hablan entre sí.
- Pipeline de especialistas: los agentes se pasan el trabajo en un orden fijo (investigación → borrador → revisión).
- Colaboración entre iguales / debate: varios agentes discuten, critican o votan.
- Jerarquías: orquestadores que gestionan a otros orquestadores.
La primera forma domina en los despliegues de producción que funcionan. Las demás aparecen más en investigación y demos.
Los argumentos a favor de varios agentes
Anthropic describió cómo construyó la función de investigación multiagente de Claude: un agente principal divide una pregunta de investigación en partes y lanza subagentes que buscan en paralelo, cada uno con su propia ventana de contexto. En su evaluación interna de investigación, el sistema multiagente superó a un agente individual en un 90,2% (Anthropic, 2025).
Por qué funcionó:
- Paralelismo. Los subagentes exploran direcciones distintas a la vez, reduciendo el tiempo real en tareas amplias.
- Contextos separados. Cada subagente puede leer decenas de miles de tokens de fuentes y devolver un resumen condensado, de modo que el contexto del agente principal se mantiene limpio. Es context engineering aplicado a nivel de arquitectura.
- Más razonamiento total. Su análisis encontró que el uso de tokens por sí solo explicaba la mayor parte de la varianza del rendimiento en su evaluación de navegación: los sistemas multiagente funcionan en parte porque permiten gastar más tokens de forma productiva.
Los argumentos en contra
El mismo informe es franco sobre el coste: los agentes usaban unas 4 veces más tokens que las interacciones de chat, y los sistemas multiagente unas 15 veces más. Solo merece la pena cuando el valor de la tarea es alto.
Cognition, el equipo detrás del agente de programación Devin, defendió en Don't build multi-agents que, en tareas como programar, repartir el trabajo entre agentes que no comparten todo el contexto lleva a decisiones contradictorias: un subagente da estilo a un componente de una forma, otro construye una pieza complementaria de otra forma y la combinación falla. Sus principios: compartir el contexto completo y las trazas completas de los agentes, y recordar que las acciones llevan decisiones implícitas que entran en conflicto si se toman de forma aislada.
La investigación respalda esta fragilidad. Un estudio que analizó trazas de varios frameworks multiagente populares construyó una taxonomía de 14 modos de fallo agrupados en problemas de especificación y diseño del sistema, desalineación entre agentes, y verificación y terminación de las tareas (Cemri et al., 2025). Muchos fallos no venían de los modelos, sino del diseño del sistema: roles poco claros, información perdida en los traspasos, nadie responsable de verificar el resultado final.
Cómo conciliar las dos visiones
Las dos posturas son menos contradictorias de lo que parecen:
| Propiedad de la tarea | Favorece multiagente | Favorece un solo agente |
|---|---|---|
| ¿Subtareas independientes? | Sí: investigación, búsqueda, recogida de datos | No: ediciones muy acopladas, diseño |
| ¿Cómo se combina la salida? | Resúmenes, listas, hallazgos | Un único artefacto coherente (código, documento) |
| Contexto por subtarea | Grande (muchas fuentes) | Pequeño o compartido |
| Valor por tarea | Alto; los tokens son baratos en relación con el valor | Bajo o de gran volumen |
| Tolerancia a la latencia | El paralelismo ayuda en el tiempo real | Un solo bucle es más sencillo |
Las tareas de lectura intensiva y en amplitud —investigación, due diligence, análisis de la competencia, investigación de logs en muchos servicios— se benefician de los subagentes. Las tareas de escritura intensiva y muy acopladas —implementar una funcionalidad, redactar un contrato— suelen funcionar mejor con un solo agente que tiene todo el contexto, quizá usando subagentes solo para investigación de solo lectura.
Diseñar un sistema orquestador-subagentes
Si tu tarea encaja, estas prácticas, sacadas del informe de Anthropic y de mis propios proyectos, mejoran la fiabilidad:
Haz explícita la delegación
El agente principal debe dar a cada subagente un encargo completo: objetivo, formato de salida, herramientas que usar, límites ("solo fuentes de 2024 en adelante", "no edites archivos") y cuánto esfuerzo dedicar. Una delegación vaga ("investiga el mercado") produce trabajo duplicado y huecos.
Subagent brief:
Objective: Find pricing for the top 5 Spanish e-commerce platforms for
SMB merchants (monthly fee, transaction fee, setup cost).
Scope: Official pricing pages and their 2026 updates only.
Output: JSON array [{platform, monthly_fee_eur, transaction_fee_pct,
setup_fee_eur, source_url, retrieved_on}]. Use null if not published.
Budget: max 10 searches. Stop when all 5 are covered.
Do not: speculate about unpublished prices.
Ajusta el esfuerzo a la tarea
Enseña al orquestador cuántos subagentes usar: uno para un dato sencillo, unos pocos para una comparación, más para una investigación amplia. Sin guía, los agentes tienden a lanzar demasiados subagentes en preguntas fáciles.
Devuelve resultados condensados y estructurados
Los subagentes deberían devolver hallazgos estructurados con fuentes, no transcripciones en bruto. Los artefactos grandes van a un almacenamiento compartido (archivos, una base de datos) y se devuelven referencias, para no inundar al agente principal.
Verifica al final
Alguien tiene que comprobar la salida final frente a la pregunta original: un paso de verificación dedicado, un comprobador de citas o una persona. La falta de verificación es una de las principales categorías de fallo de la taxonomía de Cemri.
Diseña para un estado de larga duración
Las ejecuciones multiagente duran de minutos a horas. Planifica los fallos a mitad de ejecución: guarda puntos de control del progreso, haz idempotentes las llamadas a herramientas y reanuda en lugar de empezar de cero. Se aplican los mismos patrones de fiabilidad que en cualquier sistema distribuido; consulta fiabilidad de las APIs de LLM.
La observabilidad no es opcional
Depurar un sistema multiagente sin trazas es casi imposible: el fallo puede estar en el plan del agente principal, en la búsqueda de un subagente o en la síntesis. Traza cada agente como un span con su encargo, sus llamadas a herramientas, sus tokens y su salida, vinculado al padre. Las convenciones semánticas GenAI de OpenTelemetry y las herramientas específicas de LLM lo hacen manejable; consulta observabilidad y trazas de LLM. Sigue el coste por ejecución: un solo orquestador con un mal prompt puede lanzar decenas de subagentes.
Evaluar sistemas multiagente
Evalúa primero los resultados finales: ¿la respuesta final es correcta, completa y está bien documentada? Usa LLM-as-a-judge con rúbricas, calibrado con revisión humana, como se describe en evals de LLM. Después evalúa el proceso: número de subagentes, trabajo duplicado, tokens por tarea, tiempo hasta completarla. Empieza con conjuntos de evaluación pequeños: Anthropic señala que al principio un par de docenas de consultas realistas revelan efectos grandes; no necesitas cientos para ver si un cambio ayuda.
El modelo de costes antes de construir
Un cálculo aproximado evita sorpresas:
Single agent: ~30k tokens/task × $X per 1M tokens
Multi-agent: lead 40k + 5 subagents × 60k = ~340k tokens/task (~11x)
Worth it if: value_of_better_answer × tasks/month > extra_cost × tasks/month
Para un informe de due diligence que vale horas de trabajo de un analista, 11 veces más tokens es una minucia. Para un chatbot de soporte que responde miles de preguntas sencillas al día, es ruinoso. El routing de modelos —un modelo potente para el agente principal y otros más baratos para los subagentes— reduce la diferencia; consulta optimización de costes de LLM.
Casos de uso de negocio que encajan
- Investigación y análisis: estudios de mercado, comparativas de proveedores, investigación normativa en muchos documentos.
- Investigación de incidentes: los subagentes examinan en paralelo los logs, las métricas y los despliegues recientes de distintos servicios.
- Revisión de grandes documentos: contratos o pliegos de licitación divididos en secciones, cada una analizada en busca de riesgos concretos, y después consolidados.
- Enriquecimiento de datos: muchos registros independientes enriquecidos en paralelo, cada uno por un subagente con herramientas de búsqueda.
Casos que normalmente no encajan: chat con clientes, procesamiento de formularios, cambios de código en un solo módulo, todo lo que sea sensible a la latencia. Para ellos, un workflow o un solo agente es la mejor arquitectura.
Preguntas frecuentes
¿Los subagentes necesitan modelos distintos? No necesariamente. Un modelo principal potente con subagentes más baratos es una optimización de costes habitual, pero mide la calidad: subagentes débiles producen hallazgos débiles.
¿Deberían los agentes hablar directamente entre sí? Rara vez. Un esquema en estrella a través del orquestador es más fácil de depurar y controlar que las conversaciones libres entre agentes.
¿Sirve de algo el "debate entre agentes"? La investigación muestra que el debate y la autocrítica pueden mejorar algunas tareas de razonamiento, pero las ganancias son irregulares y los costes altos. Un único paso de evaluación con criterios claros suele bastar.
¿Y los frameworks para sistemas multiagente? Ayudan con la fontanería (estado, traspasos, trazas). Las partes difíciles —descomposición de tareas, encargos, verificación— siguen siendo trabajo de diseño tuyo.
Fuentes
- Anthropic (2025). How we built our multi-agent research system.
- Cognition (2025). Don't build multi-agents.
- Cemri et al. (2025). Why Do Multi-Agent LLM Systems Fail?
- Anthropic (2024). Building effective agents.
- Du et al. (2023). Improving Factuality and Reasoning in Language Models through Multiagent Debate.
- OpenTelemetry. Semantic conventions for generative AI.