Arquitectura multiagente: dividir a ciegas os va a salir caro
Cuatro patrones de arquitectura multiagente comparados con datos reales. Cuándo dividir agentes mejora un 90% y cuándo empeora todo.
“¿Si divido mi agente en varios agentes, funcionará mejor?” Es la pregunta que más se repite en las comunidades de desarrollo con IA desde principios de 2026. Y la respuesta honesta es: depende. La investigación de Anthropic muestra que una arquitectura multiagente puede mejorar el rendimiento hasta un 90%, pero solo cuando se elige el patrón adecuado para el problema adecuado. Dividir por dividir no solo no ayuda - empeora las cosas.
El error más habitual es asumir que más agentes equivale automáticamente a más inteligencia. En realidad, cada agente adicional introduce latencia, consumo de tokens y complejidad de coordinación. La clave está en saber cuándo merece la pena pagar ese coste y qué patrón minimiza la sobrecarga.
Vamos a analizar los cuatro patrones principales, compararlos en escenarios reales y cerrar con una guía práctica para elegir.
Los cuatro patrones de arquitectura multiagente
Subagentes: el modelo orquestador-trabajador
Un agente principal actúa como orquestador e invoca agentes especializados como si fueran herramientas. Cada subagente recibe una tarea concreta, la ejecuta y devuelve el resultado al orquestador, que agrega las respuestas.
- Paralelismo fuerte: el orquestador puede lanzar varios subagentes simultáneamente, lo que reduce drásticamente el tiempo total en tareas independientes
- Enrutamiento centralizado: toda la comunicación pasa por el agente principal, lo que simplifica la trazabilidad y el control de errores
- Aislamiento de contexto: cada subagente opera con un contexto limpio y enfocado, sin contaminación de las otras ramas de trabajo
El inconveniente es que el orquestador se convierte en un cuello de botella si la lógica de enrutamiento es compleja. Además, cada invocación de subagente tiene un coste fijo en tokens por el prompt del sistema y las instrucciones de la herramienta.
Skills: un solo agente, múltiples personalidades
En lugar de crear agentes separados, un único agente carga prompts expertos según la tarea. Es como si el mismo profesional cambiase de sombrero dependiendo de lo que toca hacer.
- Ligero: no hay overhead de crear y destruir instancias de agente. El cambio de skill es simplemente un cambio de prompt
- Acumulación de contexto: al permanecer en una única sesión, el agente conserva todo el historial previo, lo que es ideal para conversaciones iterativas
- Simplicidad operativa: un solo proceso, un solo flujo de logs, un solo punto de supervisión
La desventaja principal es que el contexto crece con cada interacción. En tareas que requieren muchas iteraciones o dominios muy distintos, la ventana de contexto se satura y la calidad se degrada.
Handoffs: el relevo por etapas
El agente activo se intercambia en cada fase del flujo de trabajo. El agente A completa su parte y cede el control al agente B, que a su vez lo cede al agente C. Es un modelo puramente secuencial, como una cadena de montaje.
- Secuencial por naturaleza: cada etapa se ejecuta completamente antes de pasar a la siguiente, lo que garantiza un orden estricto
- Contexto fresco en cada etapa: el agente entrante recibe un resumen del estado actual, no el historial completo, lo que reduce la contaminación
- Ideal para pipelines: flujos como planificación, implementación, revisión y despliegue encajan de forma natural en este modelo
El punto débil es la imposibilidad de paralelizar. Si tenéis tres dominios independientes que analizar, los handoffs los procesan uno a uno. Además, la calidad del resumen entre etapas es crítica: si se pierde información en el relevo, el siguiente agente trabaja con un contexto incompleto.
Router: clasificar, despachar y agregar
Un enrutador clasifica la petición entrante, la despacha al agente o agentes apropiados en paralelo y agrega los resultados. A diferencia de los subagentes, el router es completamente stateless - no mantiene contexto entre peticiones.
- Paralelismo real: el router puede despachar a múltiples agentes simultáneamente sin necesidad de un orquestador con estado
- Desacoplamiento total: cada agente trabaja de forma completamente independiente, lo que facilita el escalado horizontal
- Agregación limpia: los resultados se combinan en una capa final sin interferencias entre las ramas
El coste es la falta de estado compartido. Si una tarea requiere que un agente sepa lo que otro ha descubierto, el patrón router no es la mejor opción.
Comparativa en tres escenarios reales
La teoría está bien, pero lo que importa es cómo se comporta cada patrón en la práctica. Vamos a analizar tres escenarios habituales con datos concretos de consumo.
Escenario 1: tarea única y sencilla
Imaginad una petición directa: “Resume este archivo de 500 líneas”. Una sola tarea, un solo dominio.
| Patrón | Llamadas al LLM | Tokens aproximados |
|---|---|---|
| Agente único | 1 | ~2K |
| Subagentes | 4 (orquestador + 3 workers) | ~8K |
| Skills | 3 (carga skill + ejecución + formato) | ~5K |
| Handoffs | 3 (análisis + resumen + revisión) | ~6K |
Resultado: el agente único gana por goleada. Para tareas simples, la sobrecarga de coordinación de cualquier patrón multiagente es puro desperdicio. Si vuestra tarea se resuelve en una sola llamada, no la compliquéis.
Escenario 2: conversación iterativa con contexto acumulado
Pensad en un chatbot de soporte técnico que necesita mantener el hilo de la conversación durante varias interacciones. El usuario pregunta, el agente responde, el usuario profundiza, y así sucesivamente durante cinco o seis turnos.
| Patrón | Llamadas totales (5 turnos) | Tokens totales |
|---|---|---|
| Subagentes | 8 (re-invocación constante) | ~20K |
| Skills | 5 (misma sesión, acumulación) | ~12K |
| Handoffs | 5 (relevo por turno) | ~13K |
| Router | 10 (clasificación + despacho por turno) | ~25K |
Resultado: skills y handoffs ganan con un 40% menos de llamadas que los subagentes. La razón es sencilla: los patrones con estado reutilizan el contexto acumulado en lugar de reconstruirlo desde cero en cada interacción. Si estáis construyendo algo conversacional, los patrones sin estado son un derroche.
Escenario 3: análisis multidominio en paralelo
Ahora imaginad la petición: “Compara el rendimiento de Python, JavaScript y Rust para procesamiento de datos”. Tres dominios independientes, cada uno con su propio análisis de aproximadamente 2.000 tokens.
| Patrón | Llamadas totales | Tokens totales |
|---|---|---|
| Subagentes | 4 (1 orquestador + 3 paralelos) | ~9K |
| Skills | 3 (secuencial, mismo agente) | ~15K |
| Handoffs | 3 (secuencial, relevo) | ~14K |
| Router | 4 (1 clasificación + 3 paralelos) | ~9K |
Resultado: subagentes y router ganan con un 40% menos de tokens que skills. La explicación es que los patrones paralelos procesan los tres dominios simultáneamente, mientras que en el modelo secuencial el contexto se arrastra de un dominio al siguiente. Con skills, el agente acumula los tokens de Python cuando analiza JavaScript, y los de ambos cuando analiza Rust - una bola de nieve de contexto innecesario que consume un 67% más de tokens.
Guía de decisión: qué patrón elegir
Después de analizar los tres escenarios, el patrón se repite con claridad:
| Tipo de tarea | Patrón recomendado | Razón |
|---|---|---|
| Tarea única y simple | Agente único | La sobrecarga multiagente no se justifica |
| Conversación iterativa | Skills o Handoffs | El estado acumulado ahorra re-invocaciones |
| Múltiples dominios independientes | Subagentes o Router | El paralelismo reduce tokens y latencia |
| Pipeline secuencial estricto | Handoffs | Cada etapa opera con contexto limpio |
| Alta concurrencia sin estado | Router | Stateless facilita el escalado horizontal |
El consejo más importante: empezad con un solo agente
Existe una tentación enorme de diseñar arquitecturas multiagente desde el primer día. Es comprensible: la investigación dice que el rendimiento puede mejorar un 90%, y los patrones suenan sofisticados. Pero esa mejora del 90% solo se materializa cuando el agente único ha alcanzado un límite claro y medible.
Antes de dividir, haceos estas preguntas:
- ¿Se está degradando la calidad de las respuestas? Si el agente único funciona bien, añadid más herramientas o mejor contexto antes de dividir
- ¿Hay tareas que podrían ejecutarse en paralelo? Si todo es secuencial, la división no aporta velocidad
- ¿El contexto se está saturando? Si las sesiones largas pierden coherencia, es momento de considerar subagentes o handoffs
- ¿Tenéis métricas para comparar? Sin un baseline del agente único, no podéis medir si la división ha mejorado algo
La arquitectura correcta no es la más compleja - es la que resuelve un cuello de botella real. Empezad con un agente único bien configurado, medid dónde falla, y solo entonces elegid el patrón multiagente que ataque ese punto débil concreto.
Conclusión
La arquitectura multiagente no es una bala de plata. Es una herramienta de precisión que funciona extraordinariamente bien cuando se aplica al problema correcto y resulta contraproducente cuando se aplica a ciegas.
Los cuatro patrones - subagentes, skills, handoffs y router - no compiten entre sí. Cada uno resuelve un tipo de problema distinto. Vuestra responsabilidad como arquitectos es diagnosticar el problema antes de elegir la solución.
El dato de Anthropic es real: una mejora del 90% es posible. Pero solo si la división responde a una necesidad concreta, no a la ilusión de que más agentes equivale automáticamente a más inteligencia.
Únete al boletín
Recibe actualizaciones sobre mis últimos proyectos, artículos y experimentos con IA y desarrollo web.