Arquitectura multiagente: dividir a ciegas te va a salir caro

“Si divido mi agente en varios agentes, va a ser más inteligente?”

La respuesta es “depende”. La investigación de Anthropic muestra que los sistemas multiagente superan a los agentes individuales en un 90% - pero solo cuando se elige la arquitectura correcta. En la práctica, las diferencias de rendimiento varían enormemente según el tipo de tarea que estés resolviendo.

Acá van tres escenarios representativos que revelan cuándo cada patrón realmente rinde.

Los cuatro patrones de un vistazo

Antes de entrar en detalle, un resumen rápido de las arquitecturas:

• Subagentes: Un agente principal invoca agentes especializados como herramientas. Fuerte en ejecución paralela, pero todos los resultados deben pasar de vuelta por el agente principal
• Skills: Un solo agente carga prompts de experto de forma dinámica según lo necesite. Liviano, pero el contexto se va acumulando con el tiempo
• Handoffs: El agente activo se intercambia en cada etapa. Diseñado específicamente para flujos secuenciales, pero no puede ejecutar tareas en paralelo
• Router: Clasifica las consultas, las despacha en paralelo y agrega los resultados. Sin estado - no retiene contexto conversacional

Ahora veamos cómo se comportan en escenarios reales.

Escenario 1: Peticiones únicas

Imagina que un usuario dice “Cómprame un café” - una solicitud puntual donde un agente especializado llama a una herramienta buy_coffee.

Comparación de rendimiento:

• Subagentes: 4 llamadas (principal -> sub -> ejecución de herramienta -> regreso al principal -> respuesta)
• Skills / Handoffs / Router: 3 llamadas (ejecución directa)

Lo importante: Las tareas de una sola vez no necesitan gestión de estado, así que Skills, Handoffs y Router son los más eficientes. Los subagentes agregan un viaje de ida y vuelta extra pasando por el agente principal, y eso se traduce directamente en latencia. Para tareas simples, no tiene sentido armar una arquitectura multiagente.

En la práctica: Bots de preguntas frecuentes, ejecución de comandos simples y consultas puntuales de datos funcionan perfecto con un agente único. Usar multiagente acá es sobreingeniería.

Escenario 2: Peticiones repetidas

Ahora el usuario dice “Cómprame otro café” - la misma petición hecha dos veces. El contexto conversacional se mantiene.

Comparación de rendimiento (segundo turno):

• Subagentes: 4 llamadas -> 8 en total (sin estado, ciclo completo cada vez)
• Skills / Handoffs: 2 llamadas -> 5 en total (40% de reducción)
• Router: 3 llamadas -> 6 en total (25% de reducción)

Lo importante: Los patrones con estado como Skills y Handoffs dominan acá. Reutilizan el contexto cargado previamente y se saltan los pasos de enrutamiento e inicialización por completo. Los subagentes, que por diseño no conservan estado, repiten el ciclo completo cada vez. La contrapartida es que los subagentes ofrecen mejor aislamiento de contexto - algo que justifica el costo extra si la seguridad o el sandboxing son prioridad.

En la práctica: Chatbots, asistentes conversacionales y servicios basados en sesión necesitan patrones con estado. Si los usuarios frecuentemente dicen cosas como “hazlo igual que antes”, prioricen Skills o Handoffs. Un Router se puede envolver dentro de un agente con estado como herramienta si hace falta.

Escenario 3: Consultas multidominio

Un usuario pregunta “Compara Python vs JavaScript vs Rust” - una consulta que abarca varios dominios especializados. Supongamos aproximadamente 2K tokens de documentación de referencia por lenguaje.

Comparación de rendimiento:

• Subagentes: 5 llamadas, ~9K tokens (cada sub trabaja en contexto aislado)
• Skills: 3 llamadas, ~15K tokens (los tres contextos de skills se acumulan en el principal)
• Handoffs: 7+ llamadas, ~14K+ tokens (solo secuencial)
• Router: 5 llamadas, ~9K tokens (ejecución en paralelo)

Lo importante: Los patrones con ejecución paralela - subagentes y Router - ganan de forma contundente. Los subagentes procesan la documentación de cada lenguaje en contextos aislados, usando un 67% menos de tokens que Skills (9K vs 15K). Skills hace menos llamadas pero apila el conocimiento de los tres dominios en el contexto principal, provocando que los costos de tokens se disparen. Los Handoffs, limitados a ejecución secuencial, son la peor opción para este tipo de trabajo.

En la práctica: Sistemas de investigación, análisis comparativo de múltiples fuentes y bases de conocimiento empresariales que consultan varios dominios independientes a la vez piden subagentes o Router. Cuando se maneja conocimiento específico de dominio en grandes volúmenes, el aislamiento de contexto impacta directamente en los costos de tokens.

Guía de selección de patrón

Escenario	Patrón recomendado
Tareas puntuales	Un solo agente es suficiente
Peticiones repetidas frecuentes	Skills o Handoffs
Múltiples dominios consultados a la vez	Subagentes o Router
Flujos de trabajo secuenciales	Handoffs

Un consejo práctico más

No arranquen con multiagente. Empiecen con un agente único respaldado por buenos prompts y herramientas bien definidas. Solo recurran a patrones multiagente cuando encuentren una limitación clara - y en ese momento usen los escenarios de arriba para elegir el correcto.

La lección de la investigación de Anthropic no es “más agentes = mejor”. Lo que de verdad genera esa mejora del 90% es elegir la arquitectura correcta para la tarea correcta.