¿Cuánto cuesta la coordinación?
Empecemos por una cifra, porque marca el suelo. Según el fabricante, los agents usan aproximadamente cuatro veces más tokens que una conversación normal; los sistemas multi-agent , quince veces más.
[Cálculo propio] De ahí: un montaje multi-agent multiplica por cuatro, más o menos, el coste en tokens frente a un solo agent.
Esa cifra es la entrada. Si la descomposición no aporta cuatro veces más valor, va a pérdidas — y eso hay que saberlo antes, no después por la factura. Por qué la ganancia no está en el paralelismo lo detalla el post los subagents y el trabajo en paralelo ; de aquí en adelante este artículo va de patrones.
Cinco sistemas, resultados medidos
El mejor dato accesible sobre esto es un estudio académico que procesó 1.642 trazas de ejecución anotadas sobre siete frameworks multi-agent. De cinco de ellos publicó tasas de éxito comparables:
| Qué hace el sistema | Tipo de tarea | Éxito |
|---|---|---|
| Problemas matemáticos de enunciado | cálculo | 84,8 % |
| Sistema de desarrollo A | escribir código | 66,0 % |
| Sistema de corrección de errores | incidencias reales | 25,3 % |
| Sistema de desarrollo B | escribir código | 25,0 % |
| Sistema que usa aplicaciones | llamadas encadenadas | 13,3 % |
Y la frase de apertura del estudio es esta: pese al entusiasmo por los sistemas multi-agent, su ganancia en los benchmarks populares suele ser mínima.
Mira la forma de esa tabla. Las filas que salieron bien son todas tareas cerradas, cortas y comprobables. Las que salieron mal son todas largas, abiertas y de muchos pasos. No es casualidad — y es justo de lo que va elegir un patrón.
Los seis patrones
La documentación primaria distingue seis montajes. Vale la pena aprenderse los nombres, porque con ese vocabulario la frase «usemos varios agents» se convierte en una decisión de diseño concreta:
| Patrón | Qué hace |
|---|---|
| Encadenado | Parte la tarea en una secuencia fija de pasos; cada llamada procesa la salida de la anterior. |
| Enrutado | Clasifica la entrada y la dirige al tratamiento especializado que le toca. |
| Paralelización | Varias llamadas trabajan a la vez y las salidas se agregan por código. |
| Orquestador y trabajadores | Un modelo central descompone sobre la marcha, delega y luego cose el resultado. |
| Evaluador y corrector | Una llamada responde, otra la puntúa y da retorno, en bucle. |
| Agent autónomo | Planifica y actúa por su cuenta, y vuelve al humano solo por información o por una decisión. |
De los seis, cuatro suelen devolver el coste de la coordinación y dos solo rara vez.
Los cuatro que salen a cuenta
1. Enrutado — la ganancia más barata
Un modelo pequeño y rápido clasifica la entrada, y a partir de ahí lo gestiona el prompt especializado que corresponde. El sobrecoste es una sola llamada corta, y la ganancia es que cada rama recibe un prompt de sistema enfocado.
Va bien cuando las categorías se separan de verdad y la clasificación es fiable. Va mal cuando el caso límite es frecuente, porque la tarea que cae en la rama equivocada se queda en la rama equivocada hasta el final.
2. Encadenado — precisión a cambio de latencia
Secuencia fija de pasos: esquema, después comprobación, después desarrollo. No es dinámico, no decide nada, y eso lo hace previsible y depurable.
Es el patrón más infravalorado. No es emocionante, pero la mayoría de las tareas de negocio son justo así: los pasos se conocen de antemano. Aquí el coste en tokens no se cuadruplica, solo crece con el número de pasos, y la salida de cada paso se puede comprobar. Si pasas un formato estructurado entre los pasos, la cadena se vuelve más robusta, y para eso da asidero la introducción a la salida estructurada , con ejemplos.
3. Paralelización — si las partes son de verdad independientes
Tiene dos variantes, y conviene distinguirlas:
- Troceado: la entrada se puede cortar en piezas independientes (cien documentos, cien llamadas).
- Varios puntos de vista: ejecutas la misma tarea desde distintos ángulos, y la coincidencia sube la confianza.
La palabra clave de la definición es que las salidas se agregan por código. En cuanto le encargas también el cosido a un modelo, has pasado al patrón del orquestador, y con él a sus fallos.
4. Evaluador y corrector — el único con pruebas duras
Es el patrón mejor respaldado, y detrás de él hay dos mediciones que se complementan.
Una es negativa: un resultado académico de 2024 dice que los modelos no saben corregirse sin retorno externo — es más, después de autocorregirse su rendimiento a veces empeora. O sea, la autocomprobación del tipo «piénsalo otra vez» no compensa.
La otra es positiva: en el mismo estudio multi-agent probaron dos intervenciones con el mismo modelo base, cambiando solo el montaje del sistema:
| Intervención | Mejora |
|---|---|
| Definición más precisa de roles y flujo | +9,4 puntos porcentuales |
| Un paso de verificación reforzado | +15,6 puntos porcentuales |
Este es el mensaje más importante del artículo. La diferencia no está en el modelo, sino en si el sistema tiene un punto de verificación externo. La autocomprobación no mejora; la otra llamada, la que mira desde fuera, sí — y la verificación determinista escrita en código, todavía más.
Hay una reserva importante, eso sí: los +15,6 puntos salían de una base del 25 %. La verificación mejora, pero no salva un montaje de base malo.
Los dos que rara vez salen a cuenta
5. Orquestador y trabajadores
Esto es lo que la mayoría llama «sistema multi-agent»: un modelo director decide sobre la marcha qué hace falta, y delega.
Es el patrón más potente — y el más caro. Aquí vive el multiplicador de quince veces en tokens, y aquí se concentran también los fallos de coordinación. Los fallos tempranos documentados son concretos e instructivos:
- cincuenta subagents lanzados para preguntas sencillas;
- búsqueda sin fin de fuentes que no existen;
- de tres subagents, uno recogió datos de algo completamente distinto y dos hicieron el mismo trabajo;
- instrucciones de delegación tan vagas que los subagents entendieron mal la tarea.
Sale a cuenta cuando las subtareas de verdad no se pueden definir de antemano, normalmente en investigación abierta. No sale cuando los pasos se conocen de antemano: ahí el encadenado da lo mismo a cuarta parte de precio.
La documentación propia del fabricante pide prudencia en dos sitios: en la mayoría de las tareas de programación hay menos partes realmente paralelizables que en la investigación, y — en un texto suyo de 2026 — «la mayoría de las tareas de programación convencionales no necesita un comité de revisión de cinco personas».
6. Agents totalmente autónomos que hablan entre sí
Las dos filas de abajo de la tabla medida son sistemas así. 25,0 % y 13,3 %.
La mejor explicación viene de un texto de 2025 de un fabricante de herramientas, que formula dos principios: comparte la traza entera, no solo los mensajes, y las acciones llevan decisiones implícitas, y las decisiones que se contradicen dan un mal resultado.
El ejemplo que lo acompaña es la mejor ilustración del tema. La tarea: hacer un juego sencillo de habilidad. Tras la descomposición, un subagent entiende mal el estilo y prepara un fondo que recuerda a un juego totalmente distinto; el otro dibuja un protagonista que no pega con él. El agent que cierra recibe una tarea imposible: tiene que encajar dos piezas incompatibles.
Y fíjate en el giro: ninguno de los dos subagents se equivocó. Los dos hicieron un trabajo razonable, solo que con supuestos distintos. El fallo de coordinación no se compone de respuestas malas, sino de respuestas buenas que no encajan.
¿Dónde se rompe exactamente?
La tipología completa de fallos, de 1.642 trazas, en tres categorías:
| Categoría | Proporción | El mayor modo de fallo de la categoría |
|---|---|---|
| Fallos de diseño del sistema | 44,2 % | repetición de pasos — 15,7 % |
| Desajuste entre agents | 32,3 % | razonamiento y acción que divergen — 13,2 % |
| Falta de verificación | 23,5 % | verificación defectuosa — 9,1 % |
De aquí sale una lectura sorprendente. La mayor parte de los fallos no viene de la comunicación entre agents, sino del diseño del sistema: de que el agent repite, no sabe cuándo ha terminado o no respeta la especificación recibida.
Y eso es buena noticia: la categoría más grande es aquella en la que se puede mejorar cambiando prompts y presupuestos, no la que exigiría cambiar de modelo. La segunda partida, el razonamiento y la acción que divergen — cuando el agent describe lo que va a hacer y luego hace otra cosa —, también se caza con verificación: si pides el plan en formato estructurado y lo comparas por código con los pasos ejecutados, el modo de fallo se vuelve visible.
La relación entre el número de pasos y la fiabilidad tiene su propio texto: el post la matemática de la fiabilidad deduce por qué no basta con un 95 % de precisión por paso.
Una novedad de 2026 que recoloca el cuadro
En la documentación de los modelos más nuevos ha aparecido una frase que conviene tomarse en serio: la nueva generación de modelos delega en subagents con más facilidad que la anterior. La recomendación, del mismo sitio: da indicaciones explícitas sobre qué situaciones justifican delegar, o limita el número de subagents.
Eso significa que el comportamiento multi-agent ya no es solo una decisión de arquitectura, sino también un comportamiento que depende de la versión del modelo. El mismo prompt con el mismo montaje puede, en un modelo nuevo, lanzar más agents, consumir más tokens y fallar de otra manera.
Consecuencia práctica: al cambiar de modelo hay que revisar de nuevo las reglas de descomposición, no solo los prompts. Y si tu coste se disparó de golpe tras una actualización, aquí conviene mirar primero.
El orden de decisión
1. ¿HAY UNA SECUENCIA DE PASOS CONOCIDA?
-> ENCADENADO. Barato, previsible, depurable.
2. ¿CATEGORÍAS DISTINTAS CON TRATO DISTINTO?
-> ENRUTADO. Una llamada corta es todo el coste.
3. ¿PIEZAS INDEPENDIENTES, UNIBLES POR CÓDIGO?
-> PARALELIZACIÓN. Pero que la suma NO la haga
un modelo.
4. ¿HAY UN CRITERIO DE EVALUACIÓN CLARO?
-> EVALUADOR-CORRECTOR. La medición más fuerte:
+15,6 puntos. Pero hace falta control
EXTERNO; la autocomprobación no mejora.
5. ¿DE VERDAD NO SE PUEDEN DEFINIR LOS PASOS?
-> ORQUESTADOR Y TRABAJADORES. 4x el coste en
tokens frente a un agent, y limita el número
de subagents que puede lanzar.
6. EN CUALQUIER OTRO CASO
-> UN SOLO AGENT. Este es el valor por defecto.
Los cuatro primeros puntos cubren la mayoría de las tareas de negocio — y ninguno necesita eso que coloquialmente se llama sistema multi-agent.
Malentendidos típicos
- «El sistema multi-agent es más potente.» En la medición se dispersaron entre el 13,3 % y el 84,8 %. Decide el montaje, no el número de piezas.
- «Si la tarea es compleja, hacen falta más agents.» La complejidad por sí sola no es motivo. La pregunta es si los pasos se pueden definir de antemano: si sí, el encadenado da lo mismo más barato.
- «Los agents ya se coordinarán entre ellos.» Cerca de un tercio de los fallos medidos es justo el fracaso de la coordinación — y su forma más común no es la respuesta mala, sino el supuesto que no encaja.
- «Añadimos un agent revisor y listo.» Ayuda, y de forma medible, con 15,6 puntos más, pero aquella medición partía de una base del 25 %. La verificación no arregla un montaje malo.
- «Pidámosle al modelo que se revise solo.» Sin retorno externo, la autocorrección no mejora y a veces empeora.
- «La programación es el terreno de los sistemas multi-agent.» Según la documentación primaria, en las tareas de programación hay menos partes realmente paralelizables que en la investigación.
- «El mismo montaje funcionará igual en un modelo nuevo.» Los modelos más nuevos delegan con más facilidad. El mismo prompt puede salir más caro.
Lo que conviene llevarse
La pregunta no es «cuántos agents uso», sino qué patrón encaja con la tarea. Cuatro de los seis — el encadenado, el enrutado, la paralelización y la pareja evaluador-corrector — son baratos y previsibles. Los dos restantes son potentes, pero caros, y la mayoría de los fallos medidos se genera ahí.
Una sola cifra que conviene recordar: más 15,6 puntos por un paso de verificación externo, con el mismo modelo. Si vas a construir una sola cosa, construye esa — y no se la pidas al modelo, ponla tú desde fuera.
Y la mejor pregunta de autocontrol antes de diseñar: ¿puedes escribir los pasos de antemano? Si puedes, no necesitas un sistema multi-agent: necesitas una cadena. Cómo se mide y se vigila el sistema terminado lo recorre entero el post probar y monitorizar tus agents , paso a paso.