El número del fabricante, y por qué no basta
El dato más citado procede de una publicación de un fabricante de junio de 2025: la combinación de un agent principal más potente con subagents más débiles superó en un 90,2 % a ese mismo modelo potente trabajando solo.
Lleva tres matices, y los tres los describe la misma fuente:
- La evaluación es interna, y la tarea consistía en buscar a los miembros del consejo de administración del sector informático de un índice bursátil. Es una búsqueda de tipo anchura, paralelizable: el caso más favorable para el montaje multi-agent.
- El coste en tokens: los agents usan alrededor de cuatro veces más tokens que una conversación; los sistemas multi-agent, quince veces más.
- Y lo más importante: «el consumo de tokens explica por sí solo el 80 % de la varianza.»
Esa última frase viene a decir que la mayor parte de la mejora no sale de la arquitectura, sino de haber calculado más.
(Evaluación interna, no publicada, sin metodología ni tamaño de muestra: así hay que citarla.)
La contraprueba: con el mismo presupuesto de tokens
Un estudio de abril de 2026 se planteó exactamente eso: ¿qué queda de la diferencia si fijamos el coste de cómputo?
Su formulación literal: los resultados potentes que se publican de los sistemas multi-agent «a menudo están confundidos por el mayor cómputo de inferencia. Cuando se normaliza el cómputo, los sistemas de un solo agent igualan o superan a los multi-agent».
Medido sobre tres familias de modelos, con varias arquitecturas multi-agent y el mismo presupuesto de tokens de razonamiento: el sistema de un solo agent igualó o superó sistemáticamente al multi-agent en las tareas de razonamiento de varios pasos.
Y detrás hay también una base teórica, más una predicción que es justo la tesis de este artículo:
El montaje multi-agent será competitivo cuando el aprovechamiento del contexto del sistema de un solo agent empeore, o cuando gastes más cómputo.
O sea: el valor no está en el paralelismo, sino en que la subtarea corra en una ventana limpia.
La degradación del contexto, medida
Si la tesis es el contexto limpio, hay que enseñar cuánto empeora el contexto sucio.
La conclusión principal de una serie de mediciones sobre 18 modelos, literalmente: los modelos no usan el contexto de forma uniforme; su rendimiento se vuelve cada vez menos fiable a medida que crece la longitud de la entrada.
Y el resultado parcial más afilado: basta un solo elemento fuera de lugar para empeorar respecto al caso base.
De esto hay también confirmación independiente y cuantificada. Un benchmark de llamada a funciones mide la tarea de varios turnos por separado en versión base y en versión de contexto largo, sobre los mismos modelos:
| Varios turnos, base | Varios turnos, contexto largo | Caída | |
|---|---|---|---|
| La cabeza del grupo | 63–81 % | 56–70 % | −0,5 a −10,5 puntos según el modelo |
(Cálculo propio a partir de los datos públicos del ranking. La mediana de los siete modelos medidos es de 8 puntos; en un solo modelo la caída fue de apenas 0,5 puntos: el efecto depende del modelo.)
Esta es la base numérica de la tesis del artículo: el contexto más largo, por sí mismo y al margen del número de pasos, es una pérdida medible.
A eso se suma el hallazgo ya conocido de que los modelos aprovechan mejor la información colocada al principio y al final del contexto que la del medio, y una explicación que conviene recordar: el modelo tiene un presupuesto de atención, y cada token añadido consume parte de él.
Desde aquí se entiende lo que hace de verdad un subagent: trabaja en su propia ventana limpia, gasta tokens del orden de las decenas de miles y devuelve un resumen condensado de 1.000 a 2.000 tokens. Al contexto del agent principal no entra el trabajo, sino el resultado.
¿Cuándo merece la pena?
Para esto también hay medición. Un estudio de 2025 miró las tareas en dos dimensiones: profundidad (cuán larga es la cadena de razonamiento) y anchura (cuántas capacidades distintas hacen falta).
La conclusión: la ventaja del montaje multi-agent crece en las dos dimensiones, y más con la profundidad.
Traducido a regla práctica: trocear sale rentable si las subtareas son independientes y piden capacidades distintas. Si se apoyan unas en otras, no.
¿Cuándo no?
Aquí la mejor fuente es la documentación primaria, que enuncia los casos negativos:
NO USES UN SUBAGENT SI
- la tarea exige ida y vuelta frecuente o
refinamiento iterativo;
- varias fases COMPARTEN contexto importante
(diseño, implementación y pruebas juntos);
- se trata de un cambio rápido y puntual;
- la latencia importa.
Y un detalle técnico que se desprende de ahí: el subagent arranca en una ventana nueva y aislada. No ve el histórico de la conversación ni lo que has leído hasta ahora. Eso es justo su ventaja, y justo por eso sale caro cuando la tarea necesita contexto compartido.
Lo que sí hace bien, según esa misma documentación: preservar el contexto (la exploración se queda fuera de la conversación principal), controlar el coste (la subtarea puede ir a un modelo más rápido y barato), restringir (el subagent recibe menos herramientas) y especializar (un system prompt enfocado).
Dos fabricantes, con un día de diferencia
La mejor ilustración de hasta qué punto no hay consenso en este tema.
12 de junio de 2025: un fabricante de herramientas publica un texto titulado «No construyas sistemas multi-agent». Formula dos principios: comparte el contexto, y no solo los mensajes, sino la traza completa; y las acciones llevan dentro decisiones implícitas, y las decisiones contradictorias dan malos resultados. Su frase más afilada: ejecutar varios agents a la vez en 2025 «solo produce sistemas frágiles».
13 de junio de 2025, al día siguiente: otro fabricante publica su resultado multi-agent del 90,2 %.
(El primer texto no contiene ninguna cifra medida: es experiencia y postura. El segundo cita un eval interno. Ninguno de los dos es una medición independiente.)
Fallos de coordinación, medidos
Por último, los números de qué se rompe si aun así troceas. El mismo estudio de 1.642 ejecuciones anotadas que dio la tipología de fallos:
El malentendido entre agents es el 32,3 % de los fallos. Dentro de eso:
| Modo de fallo | Proporción |
|---|---|
| Desajuste razonamiento-acción (describe qué va a hacer y luego hace otra cosa) | 13,2 % |
| Deriva de la tarea | 7,4 % |
| No pregunta para aclarar dudas | 6,8 % |
| La conversación se reinicia | 2,2 % |
| Ignorar la entrada de otro agent | 1,9 % |
| Retención de información (el «traspaso perdido») | 0,8 % |
A eso se añade aparte el 15,7 % de repetición de pasos, que es el indicador del trabajo duplicado.
Y el marco que el propio estudio plantea, que merece la pena citar: pese al entusiasmo por los sistemas multi-agent, «sus ganancias de rendimiento en los benchmarks populares suelen ser mínimas.»
La guía práctica
1. PREGUNTA PRIMERO: ¿ES INDEPENDIENTE?
Si las subtareas se apoyan entre sí, no la trocees.
Según la medición, la ganancia viene con eso.
2. EL SUBAGENT DEVUELVE RESULTADO, NO TRABAJO
Un resumen de 1-2 mil tokens. Si devuelve la traza
entera, perdiste la ventaja del contexto limpio.
3. DALE LA TAREA COMPLETA
Arranca en una ventana nueva y aislada: no ve lo
que tú sabes. Lo que no le escribes, no existe.
4. DALE MENOS HERRAMIENTAS, NO MÁS
Estrechar aquí sale gratis y mejora la precisión
de la elección.
5. MODELO MÁS BARATO PARA LA SUBTAREA
Es una de las ganancias reales y medibles del troceo.
6. MIDE LA DUPLICACIÓN
El fallo de coordinación más común es repetir pasos.
Si dos subagents hacen lo mismo, el troceo está mal.
El tercer punto es el error más frecuente. El subagent no sabe de qué habéis hablado hasta ahora, y eso no es una carencia, sino la esencia. Pero por eso mismo la descripción de la tarea tiene que ser completa por sí sola.
Malentendidos habituales
- «Más agents dan mejor resultado.» Con el mismo presupuesto de tokens, según la medición, no. La mayor parte de la mejora viene del cómputo extra.
- «Trocear acelera.» La latencia puede bajar, pero el coste en tokens se multiplica según los factores publicados.
- «El subagent ve lo que hemos hecho hasta ahora.» No. Arranca en una ventana nueva y aislada.
- «Programar es buen terreno para trocear.» Según la documentación primaria, en la mayoría de las tareas de programación hay menos partes realmente paralelizables que en la investigación.
- «Si no funciona, añadimos otro agent.» La proporción medida de fallos de coordinación está por encima del treinta por ciento, y cada agent nuevo también la aumenta.
- «El 90,2 % es una prueba.» Es una evaluación interna, en el tipo de tarea más favorable, y esa misma fuente escribe que el 80 % de la varianza lo explica el consumo de tokens.
Lo que conviene llevarse
El subagent no es una herramienta de paralelización, sino de gestión del contexto. Esa diferencia decide cuándo merece la pena.
Por eso la pregunta práctica no es «en cuántos agents lo troceo», sino qué subtarea es la que ensucia el contexto principal. La exploración, la búsqueda larga, revisar muchos archivos: esas normalmente sí. El diseño, la implementación y las pruebas juntos, con un fondo común: normalmente no.
Y una comprobación barata: si el subagent devuelve una respuesta tan larga como lo que ha trabajado, el troceo no aportó nada. Lo esencial es la condensación.
Por qué la fiabilidad empeora con el número de pasos —y por qué la autoevaluación no ayuda— lo calcula el post la matemática de la fiabilidad , tabla a tabla; y de la memoria y el olvido se ocupa el post agent memory en detalle.