Mientras que los sistemas de un solo agente gestionan la mayoría de los flujos de trabajo empresariales de forma eficaz, las arquitecturas multiagente pueden desbloquear valor adicional para tu organización. Aprender cuándo y cómo usarlas.
Un sistema multiagente es una arquitectura en la que se ejecutan múltiples instancias de LLM con contextos de conversación separados, coordinadas a través de código. Cada agente gestiona una parte distinta de una tarea (un subagente investiga mientras un orquestador planifica, por ejemplo), lo que protege el contexto, permite el trabajo en paralelo y posibilita una especialización que un agente por sí solo no puede mantener.
Existen múltiples patrones de coordinación (enjambres de agentes, sistemas basados en capacidades y arquitecturas de bus de mensajes), pero este artículo se centra en el patrón orquestador-subagente: un modelo jerárquico en el que un agente principal genera y gestiona subagentes especializados para subtareas específicas. Este patrón ofrece un modelo de coordinación sencillo y es un buen punto de partida para equipos que se inician en los sistemas multiagente. Exploraremos otros patrones en detalle en nuestro próximo artículo.
Hoy en día, los sistemas multiagente a menudo se aplican en situaciones en las que un solo agente funcionaría mejor, aunque este cálculo continúa evolucionando a medida que mejoran los modelos. En Anthropic, hemos visto a equipos invertir meses construyendo arquitecturas multiagente elaboradas solo para descubrir que mejorar el prompting en un solo agente logró resultados equivalentes.
Después de crear sistemas multiagente y trabajar con equipos que los despliegan en producción, hemos identificado tres situaciones en las que múltiples agentes superan constantemente a un solo agente: cuando la contaminación contextual degrada el rendimiento, cuando las tareas pueden ejecutarse en paralelo y cuando la especialización mejora la selección de herramientas o el enfoque en la tarea. Fuera de estas situaciones, los costes de coordinación suelen superar los beneficios.
En este artículo, compartimos cómo reconocer los límites de un solo agente, identificar los tres escenarios en los que los sistemas multiagente sobresalen y evitar errores comunes de implementación.
Un agente único bien diseñado con las herramientas adecuadas puede lograr mucho más de lo que muchos desarrolladores esperan.
Los sistemas multiagente introducen una sobrecarga. Cada agente adicional representa otro posible punto de falla, otro conjunto de prompts que mantener y otra fuente de comportamiento inesperado.
Hemos observado a equipos que construían complejos sistemas multiagente con agentes separados para planificación, ejecución, revisión e iteración, solo para descubrir que perdían contexto en cada transferencia y que gastaban más tokens coordinando que ejecutando. En nuestras pruebas, las implementaciones multiagente suelen usar entre 3 y 10 veces más tokens que los enfoques de un solo agente para tareas equivalentes. Esta sobrecarga se debe a la duplicación de contexto entre agentes, los mensajes de coordinación entre agentes y el resumen de resultados para los traspasos.
Las arquitecturas multiagente proporcionan valor cuando abordan restricciones específicas que un solo agente no puede superar. Esto significa que las arquitecturas multiagente deben reservarse para casos en los que ofrezcan beneficios claros que justifiquen ese coste adicional. La infraestructura gestionada también puede encargarse de esto por ti (consulta Orquestación multiagente en Agentes gestionados por Claude).
Los patrones que se muestran a continuación representan casos en los que observamos constantemente retornos positivos de esta inversión.
Los grandes modelos de lenguaje tienen ventanas de contexto finitas y la calidad de la respuesta puede degradarse a medida que el contexto crece. Cuando el contexto de un agente acumula información de una subtarea que es irrelevante para las subtareas posteriores, se produce contaminación de contexto. Los subagentes proporcionan aislamiento, ya que cada uno opera en su propio contexto limpio y centrado en su tarea específica.
Piensa en un agente de atención al cliente que necesite recuperar el historial de pedidos mientras diagnostica problemas técnicos. Si cada búsqueda de pedidos añade miles de tokens al contexto, la capacidad del agente para razonar sobre el problema técnico se degrada.
El enfoque de agente único:
El agente debe razonar sobre el problema técnico mientras mantiene en contexto más de 2000 tokens de historial de pedidos irrelevantes, lo que diluye la atención y reduce la calidad de la respuesta.
El enfoque multiagente:
El agente de búsqueda de pedidos procesa el historial completo de pedidos y extrae un resumen. El agente principal recibe solo los 50-100 tokens que realmente necesita, manteniendo el contexto enfocado.
El aislamiento de contexto es más eficaz cuando las subtareas generan un alto volumen de contexto (más de 1000 tokens), pero la mayor parte de esa información es irrelevante para la tarea principal, cuando la subtarea está bien definida con criterios claros sobre qué información extraer, y para operaciones de búsqueda o recuperación que requieren filtrado antes de su uso.
Ejecutar varios agentes en paralelo te permite explorar un espacio de búsqueda más amplio del que puede cubrir un solo agente. Este patrón ha demostrado ser particularmente valioso para tareas de búsqueda e investigación.
El equipo de Investigación de Anthropic documentó esto en cómo construimos nuestro sistema de Investigación multiagente. Un agente principal analiza una consulta y genera múltiples subagentes para investigar diferentes facetas en paralelo. Cada subagente busca de forma independiente y luego devuelve los hallazgos destilados. La búsqueda multiagente ha mostrado mejoras sustanciales en la precisión respecto a los enfoques de un solo agente, al permitir la exploración en espacios de información más grandes.
La implementación principal descompone una pregunta en facetas independientes, ejecuta subagentes de forma simultánea y luego sintetiza los resultados.
Esta cobertura mejorada tiene un coste. Los sistemas multiagente suelen consumir de 3 a 10 veces más tokens que los enfoques de un solo agente para tareas equivalentes. Esto sucede porque cada agente necesita su propio contexto, los agentes deben intercambiar mensajes para coordinarse y los resultados deben resumirse cuando se los pasan entre ellos. Si bien el paralelismo ayuda a reducir el tiempo total de ejecución en comparación con la ejecución de forma secuencial, los sistemas multiagente a menudo tardan más que los sistemas de un solo agente debido al gran aumento en la computación total.
El beneficio principal de la paralelización es la minuciosidad, no la velocidad. Cuando necesitas buscar en un gran espacio de información o investigar muchos ángulos de una pregunta compleja, los agentes paralelos pueden cubrir más terreno que un solo agente que trabaje dentro de sus límites de contexto. La contrapartida es un mayor uso de tokens y, a menudo, un tiempo de ejecución total más largo a cambio de resultados más completos.
Las diferentes tareas a veces se benefician de diferentes conjuntos de herramientas, prompts del sistema o áreas de especialización. En lugar de proporcionar a un solo agente acceso a docenas de herramientas, los agentes especializados con conjuntos de herramientas enfocados y adaptados a sus responsabilidades pueden mejorar la fiabilidad.
Cuando un agente tiene acceso a demasiadas herramientas, el rendimiento se resiente. Tres señales indican que la especialización en herramientas ayudaría:
Diferentes tareas a veces requieren diferentes personalidades, restricciones o instrucciones que entran en conflicto cuando se combinan. Un agente de atención al cliente debe ser empático y paciente; un agente de revisión de código debe ser preciso y crítico. Un agente de verificación de cumplimiento necesita un seguimiento estricto de las reglas, mientras que un agente brainstorming necesita flexibilidad creativa. Cuando un solo agente debe cambiar entre modos de comportamiento conflictivos, separar en agentes especializados con prompts de sistema personalizados produce resultados más coherentes.
Cada agente especializado solo es tan bueno como sus instrucciones: las mismas prácticas recomendadas de ingeniería de prompts que mejoran los resultados de un solo agente se aplican al prompt del sistema de cada subagente.
Algunas tareas se benefician de un contexto profundo de dominio que abrumaría a un agente generalista. Un agente de análisis legal podría necesitar un contexto amplio sobre jurisprudencia y marcos regulatorios. Un agente de investigación médica podría necesitar conocimientos especializados sobre metodología de ensayos clínicos. En lugar de cargar todo el contexto del dominio en un solo agente, los agentes especializados pueden contar con conocimientos especializados y específicos relevantes para sus responsabilidades concretas.
Ejemplo: integración multiplataforma. Considera un sistema de integración en el que los agentes tengan que trabajar en plataformas de CRM, automatización de marketing y mensajería. Cada plataforma tiene entre 10 y 15 endpoints de la API relevantes. Un solo agente con más de 40 herramientas a menudo tiene dificultades para seleccionar correctamente, confundiendo operaciones similares en todas las plataformas. Dividir en agentes especializados con conjuntos de herramientas enfocados y prompts personalizados resuelve los errores de selección.
Este patrón refleja una colaboración profesional eficaz, en la que especialistas con herramientas adecuadas para sus roles colaboran de forma más efectiva que los generalistas que intentan mantener su experiencia en todos los dominios. Sin embargo, la especialización introduce una complejidad de enrutamiento. El orquestador debe clasificar correctamente las solicitudes y delegar en el agente adecuado, y un mal enrutamiento conduce a resultados deficientes. Mantener múltiples agentes especializados también aumenta los gastos de mantenimiento de prompts. La especialización funciona mejor cuando los dominios son claramente separables y las decisiones de enrutamiento no son ambiguas.
Más allá del marco general, ciertas señales concretas sugieren que los patrones de un solo agente han quedado obsoletos:
Acercándose a los límites de contexto. Si un agente utiliza rutinariamente grandes cantidades de contexto y el rendimiento se está degradando, la presión contextual puede ser el cuello de botella. Ten en cuenta que los avances recientes en la gestión del contexto (como la compactación) están reduciendo esta limitación, lo que permite a los agentes individuales mantener una Memoria efectiva en horizontes mucho más largos.
Gestionando varias herramientas. Cuando un agente tiene de 15 a 20 o más herramientas, el modelo dedica una gran cantidad de contexto y atención a comprender sus opciones. Antes de adoptar una arquitectura multiagente, considera la posibilidad de usar la Tool Search Tool, que permite a Claude descubrir herramientas de forma dinámica bajo demanda en lugar de cargar todas las definiciones por adelantado. Esto puede reducir el uso de tokens hasta en un 85 % mientras mejora la precisión de la selección de herramientas.
Subtareas paralelizables. Cuando las tareas se descomponen naturalmente en partes independientes (investigación en múltiples fuentes, pruebas para múltiples componentes), los subagentes paralelos pueden proporcionar aceleraciones sustanciales.
Estos umbrales cambiarán a medida que los modelos mejoren. Los límites actuales representan directrices prácticas, no restricciones fundamentales.
Cuando se adopta una arquitectura multiagente, la decisión de diseño más importante es cómo dividir el trabajo entre los agentes. Hemos observado que los equipos con frecuencia hacen esta elección de forma incorrecta, lo que genera una sobrecarga de coordinación que anula los beneficios del diseño multiagente.
La idea clave es adoptar una visión centrada en el contexto en lugar de una visión centrada en el problema al descomponer el trabajo.
Descomposición centrada en el problema (a menudo contraproducente). Dividir por tipo de trabajo (un agente escribe funciones, otro escribe pruebas, un tercero revisa código) crea una sobrecarga de coordinación constante. Cada transferencia pierde contexto. El agente de escritura de pruebas carece de conocimientos sobre por qué se tomaron ciertas decisiones de implementación, y el revisor de código carece del contexto de exploración e iteración.
Descomposición centrada en el contexto (normalmente eficaz). Dividir por límites de contexto significa que un agente que maneje una funcionalidad también debe manejar sus pruebas, porque ya posee el contexto necesario. El trabajo solo debe dividirse cuando el contexto pueda aislarse realmente.
Este principio surge de la observación de modos de falla en sistemas multiagente. Cuando los agentes se dividen por tipo de problema, participan en un "teléfono escacharrado", pasando información de un lado a otro, degradando la fidelidad en cada traspaso. En un experimento con agentes especializados por rol de desarrollo de software (planificador, implementador, probador, revisor), los subagentes gastaron más tokens en coordinación que en el trabajo real.
Los límites de descomposición eficaces incluyen:
Los límites de descomposición problemáticos incluyen:
Un patrón multiagente que funciona bien de manera consistente en todos los dominios es el subagente de verificación. Se trata de un agente dedicado cuya única responsabilidad es probar o validar el trabajo del agente principal.
Vale la pena señalar que los modelos orquestadores más capaces (como Claude Opus 4.5) pueden cada vez más evaluar el trabajo de los subagentes directamente sin un paso de verificación separado. Sin embargo, los subagentes de verificación siguen siendo valiosos cuando usas orquestadores menos capaces, cuando la verificación requiere herramientas especializadas o cuando quieres aplicar puntos de control de verificación explícitos en tu flujo de trabajo.
Los subagentes de verificación tienen éxito porque evitan el problema del "teléfono escacharrado". La verificación requiere una transferencia de contexto mínima por naturaleza, por lo que un verificador puede probar un sistema como caja negra sin necesidad de conocer el historial completo de cómo se construyó.
El agente principal completa una unidad de trabajo. Antes de continuar, genera un subagente de verificación con el artefacto para verificar, criterios de éxito claros y herramientas para realizar la verificación.
El verificador no necesita entender por qué el artefacto se construyó de la forma en que se construyó. Solo necesita determinar si el artefacto cumple los criterios especificados.
Los subagentes de verificación son efectivos para:
El modo de fallo más significativo para los subagentes de verificación es marcar las salidas como aprobadas sin realizar pruebas exhaustivas. El verificador ejecuta una o dos pruebas, observa que se superan y declara el éxito.
Las estrategias de mitigación incluyen:
Los sistemas multiagente son potentes, pero no siempre son apropiados. Antes de añadir la complejidad de varios agentes coordinados, confirma que:
¿Nuestro consejo? Empieza con el enfoque más simple que funcione y añade complejidad solo cuando las pruebas lo avalen.
Esta es la primera de una serie de publicaciones sobre sistemas multiagente. Para obtener más información sobre patrones de agente único, consulta Crear agentes eficaces. Para obtener información sobre estrategias de gestión de contexto, consultar Ingeniería contextual eficaz para agentes de IA. Para obtener una descripción más detallada de cómo construimos nuestro sistema de investigación multiagente, consultar Cómo construimos nuestro sistema de investigación multiagente.
Escrito por Cara Phillips, con contribuciones de Paul Chen, Andy Schumeister, Brad Abrams y Theo Chu.
Recibir el boletín para desarrolladores
Actualizaciones de productos, guías prácticas, aspectos destacados de la comunidad y más. Enviado mensualmente a tu bandeja de entrada.
