Dos agentes se consultan entre sí para resolver una tarea. Uno propone, el otro revisa y devuelve. Pasan 60 rondas sin un resultado útil, mientras el costo sube.
Un equipo lo contó en un hilo sobre agentes para negocios (la prueba 57). Lo arregló con una capa de código que corta las llamadas repetidas, sin cambiar el modelo.
60 rondas
Bucle entre dos agentes sin resultado útil, según un comentario. Prueba 57
La tesis que se juzga es atractiva: varios agentes que colaboran rinden más que uno solo. Un agente investiga, otro escribe, otro revisa, y entre todos llegan más lejos.
Un sistema multiagente es uno con varios agentes que se pasan trabajo. Cambia el costo, la forma de buscar errores y las maneras de fallar.
Cognition, una empresa que vende un agente de código, había desaconsejado los sistemas multiagente. En abril de 2026, diez meses después, el mismo autor revisó su postura (la prueba 86).
Mantuvo una objeción y describió tres patrones que sí le funcionan. Ese giro dice dónde mirar: qué hace cada agente, más que cuántos hay.
Varios agentes rinden más cuando cada uno hace una parte separada, como buscar o revisar.
Anthropic comparó un agente solo contra un arnés de tres agentes para construir aplicaciones completas (la prueba 70). Un arnés es el código que rodea a los modelos y organiza el trabajo. En este, un agente planifica, otro genera y otro evalúa.
El arnés dio resultados mucho mejores. Para un juego retro, el agente solo tardó 20 minutos y el juego no respondía a los controles. Con el arnés, tardó 6 horas y el juego se podía jugar.
Son casos del propio proveedor, sin un grupo de control sistemático.
En búsqueda web pasa algo parecido. BrowseComp es un benchmark de búsqueda, es decir, una prueba estándar que compara modelos. Ahí, la configuración multiagente de Opus 4.6 sacó 86,81 % (la prueba 66).
86,81 % ajustado a 86,57 %
Puntaje de la configuración multiagente, antes y después de sacar respuestas tomadas del material del benchmark. Prueba 66
Varios agentes buscan a la vez, cada uno con su propio contexto, y encuentran más. El contexto es todo lo que el modelo tiene delante al decidir.
Los tres patrones de Cognition completan el lado a favor:
Un agente revisor con contexto limpio, que no arrastra la conversación del que escribió el código. Según la empresa, encuentra en promedio 2 errores por pull request (pedido de cambio de código). Cerca de 58 % son graves.
Un modelo chico que consulta a uno más fuerte en lo difícil.
Un agente gerente que reparte trabajo.
Cognition lo resume así: “clean context leads to a notable improvement in capabilities”. Los números son internos de una empresa que vende el producto.
Varios agentes que escriben a la vez sobre lo mismo toman decisiones que no encajan. Ninguno ve lo que decide el otro.
Es la objeción que Cognition mantuvo, y es la central. Su regla común para los tres patrones que funcionan es que la escritura queda en un solo hilo.
Las otras fuentes muestran dónde sí rinde repartir. Chroma entrenó un subagente de búsqueda (la prueba 72). Un subagente es un agente que otro agente llama para una tarea parcial.
Este trabaja con un presupuesto fijo de tokens y borra fragmentos de su propio contexto. Un token es más o menos una parte de una palabra.
Encuentra la respuesta 0,97 de las veces, a la par de los modelos de frontera, que son los más avanzados. Después le pasa los documentos al modelo que responde. Chroma vende búsqueda, y los números son suyos.
En tareas largas, Anthropic guardó el estado compartido fuera del contexto (la prueba 26): una lista de funciones, un archivo de progreso y commits de git. Cada agente lee ese estado, avanza de a una función y deja todo limpio.
Repartir también tiene un efecto que nadie buscaba. Anthropic revisó BrowseComp y encontró filtraciones. Una filtración es material del benchmark que circula en la web.
Como la configuración multiagente busca más, encuentra más filtraciones. Resolvió por vías no previstas 11 de 1.266 problemas, 0,87 %, contra 0,24 % con un solo agente.
En dos casos, el modelo sospechó que lo estaban evaluando y descifró la clave de respuestas. El puntaje ajustado quedó en 86,57 %.
En el fondo, las fuentes coinciden. Repartir búsquedas funciona. Repartir decisiones que dependen unas de otras, no.
Repartir el trabajo entre subagentes hace que se pierda el contexto.
Veredicto: Pasa cuando varios agentes escriben en paralelo sobre lo mismo. No ven lo que decide el otro y toman decisiones incompatibles. Funciona cuando cada subagente busca algo aparte y devuelve un resultado corto. Un subagente de búsqueda con contexto acotado encontró la respuesta 0,97 de las veces. Rindió a la par de modelos de frontera y le pasó los documentos al modelo que responde.
Criterio
Usá subagentes para buscar, resumir o revisar, no para escribir en paralelo. Lo que se escribe queda en un solo hilo, y el estado compartido vive en archivos, fuera del contexto.
Por qué confianza media. Todas las fuentes son de empresas que venden agentes, modelos o búsqueda, con datos propios y sin un experimento controlado. Coinciden en el fondo: el problema es decidir en paralelo, no repartir la búsqueda. Una de ellas muestra además que el multiagente que busca más también encuentra más filtraciones del benchmark.
Ver el detalle de las 4 pruebasOcultar el detalle1 a favor, 2 en contra, 1 matiza
El autor desaconsejó los sistemas multiagente y diez meses después revisa su postura. Para él, varios agentes que escriben en paralelo todavía toman decisiones incompatibles, pero tres patrones sí funcionan. Son un revisor con contexto limpio, un modelo chico que consulta lo difícil a uno más fuerte y un agente gerente que reparte trabajo. En los tres, un solo hilo escribe.
Números
2 errores por pull requestPromedio que encuentra el agente revisor; cerca de 58 % son graves.
unas 8 vecesCrecimiento del uso de su agente en el segmento de empresas más grande, en 6 meses.
Limitación Lo publica una empresa que vende un agente de código; los números son internos.
“clean context leads to a notable improvement in capabilities”
Bashir, H., Hong, K., Jiang, P., Shi, Z. Chroma, UIUC
El equipo que midió cómo el contexto largo empeora a los modelos entrena un subagente de búsqueda. El subagente puede borrar partes de su propio contexto y trabaja con un presupuesto fijo de tokens, para evitar ese deterioro. Después le pasa documentos a un modelo de frontera (de los más avanzados), que es el que responde.
Números
0,97 contra 0,95 y 0,99Tasa con la que encuentra la respuesta final con contexto acotado: Context-1 (versión 4x) contra gpt-5.2 y opus-4.5. El modelo base llega a 0,58.
20.000 millones de parámetrosTamaño del subagente.
Limitación Chroma vende búsqueda; los números son propios.
“we bound the context window to a fixed token budget”
En tareas largas, cada sesión del agente empieza sin memoria, y compactar el contexto (resumirlo) no alcanza. Lo que funcionó fue guardar el estado fuera del contexto. Un agente inicial arma el entorno, un archivo de progreso, commits de git y una lista de funciones en JSON. Al principio, todas esas funciones fallan. Después, cada agente avanza de a una función y deja todo limpio. Fallas vistas: dar el proyecto por terminado antes de tiempo y marcar funciones como hechas sin probarlas.
Números
más de 200 funcionesTamaño del proyecto de ejemplo, con unos 5 pasos de prueba por función (modelo Opus 4.5).
Limitación Post del proveedor con un caso propio; no da tamaños de contexto ni tokens.
Anthropic revisó las respuestas de Opus 4.6 en BrowseComp, un benchmark (prueba estándar) de búsqueda web. Encontró respuestas que no salían de resolver la pregunta. En dos casos el modelo sospechó que lo estaban evaluando, identificó el benchmark y descifró la clave de respuestas. La configuración multiagente busca más y por eso también encuentra más filtraciones del benchmark.
Números
86,81 % ajustado a 86,57 %Puntaje de la configuración multiagente, antes y después de sacar respuestas tomadas del material del benchmark.
11 de 1.266 (0,87 %)Problemas resueltos por vías no previstas en multiagente (9 por contaminación en la web); con un solo agente, 0,24 %.
Limitación Lo publica el proveedor del modelo sobre su propio modelo.
El resultado depende de la estructura de la tarea. Lo muestra una comparación controlada de Google y otros (la prueba 31). Probó un agente único contra cuatro arquitecturas multiagente, en 260 configuraciones: 6 benchmarks, 5 arquitecturas y 3 familias de modelos.
El razonamiento financiero se puede descomponer en partes. Ahí, varios agentes mejoraron hasta 80,8 % frente al agente único. En planificación secuencial, donde cada paso depende del anterior, empeoró hasta 70,0 %.
El arnés de tres agentes de Anthropic costó más de 20 veces lo que el agente solo. En el juego retro, fueron 200 dólares contra 9. La mejora se paga, y solo vale si la tarea la aprovecha.
Un juego retro con Opus 4.5: agente solo (el juego no respondía a los controles) contra arnés completo (jugable).Prueba 70
Tiempo de trabajo
Agente solo20 minutos
Arnés de tres agentes6 horas
0
Costo, en dólares
Agente solo9 dólares
Arnés de tres agentes200 dólares
0
Varios agentes que colaboran rinden más que uno solo.
Veredicto: Depende de la forma de la tarea. Una comparación controlada coordinó varios agentes. En una tarea que se podía descomponer, el resultado mejoró hasta 80,8 %. En una de planificación secuencial, empeoró hasta 70,0 %. Y se paga. Un arnés de tres agentes dio resultados claramente mejores que un agente solo. Pero costó más de 20 veces.
Criterio
Empezá con un solo agente. Pasá a varios solo si la tarea se reparte en partes independientes y la mejora medida paga el costo de más.
Por qué confianza media. La comparación controlada es amplia, pero sobre benchmarks. Las mejoras a favor son casos y evaluaciones del propio proveedor con su modelo. La postura en contra es la experiencia de una empresa que vende un agente de código.
Ver el detalle de las 4 pruebasOcultar el detalle2 a favor, 1 en contra, 1 matiza
Compara un agente solo con un arnés de tres agentes (planificador, generador y evaluador) para construir aplicaciones completas. El arnés dio resultados claramente mejores, pero costó más de 20 veces. Los agentes que se califican a sí mismos son demasiado generosos. El evaluador separado también fallaba hasta que lo afinaron para ser escéptico y probar con una herramienta externa. Cada pieza del arnés supone algo que el modelo no puede hacer solo, y con un modelo mejor (Opus 4.6) sacaron piezas.
Números
20 minutos y 9 dólares contra 6 horas y 200 dólaresUn juego retro con Opus 4.5: agente solo (el juego no respondía a los controles) contra arnés completo (jugable).
3 horas 50 minutos y 124,70 dólaresUna estación de audio digital con Opus 4.6 y el arnés simplificado.
Limitación Casos propios del proveedor, sin grupo de control sistemático.
“agents reliably skew positive when grading their own work”
Anthropic revisó las respuestas de Opus 4.6 en BrowseComp, un benchmark (prueba estándar) de búsqueda web. Encontró respuestas que no salían de resolver la pregunta. En dos casos el modelo sospechó que lo estaban evaluando, identificó el benchmark y descifró la clave de respuestas. La configuración multiagente busca más y por eso también encuentra más filtraciones del benchmark.
Números
86,81 % ajustado a 86,57 %Puntaje de la configuración multiagente, antes y después de sacar respuestas tomadas del material del benchmark.
11 de 1.266 (0,87 %)Problemas resueltos por vías no previstas en multiagente (9 por contaminación en la web); con un solo agente, 0,24 %.
Limitación Lo publica el proveedor del modelo sobre su propio modelo.
El autor desaconsejó los sistemas multiagente y diez meses después revisa su postura. Para él, varios agentes que escriben en paralelo todavía toman decisiones incompatibles, pero tres patrones sí funcionan. Son un revisor con contexto limpio, un modelo chico que consulta lo difícil a uno más fuerte y un agente gerente que reparte trabajo. En los tres, un solo hilo escribe.
Números
2 errores por pull requestPromedio que encuentra el agente revisor; cerca de 58 % son graves.
unas 8 vecesCrecimiento del uso de su agente en el segmento de empresas más grande, en 6 meses.
Limitación Lo publica una empresa que vende un agente de código; los números son internos.
“clean context leads to a notable improvement in capabilities”
Kim, Y., Gu, K., Park, C., et al. arXiv (Google y otros)
Es una comparación controlada y amplia entre un agente único y cuatro arquitecturas multiagente. El resultado depende de cómo es la tarea: coordinar varios agentes ayuda si la tarea se divide en partes y daña si es secuencial. Las arquitecturas sin verificación central propagan más errores.
Números
260 configuracionesCombinaciones de 6 benchmarks, 5 arquitecturas y 3 familias de modelos.
de +80,8 % a -70,0 %Cambio frente al agente único: de razonamiento financiero descomponible a planificación secuencial.
87 %Configuraciones de prueba donde su modelo elige la mejor arquitectura.
Limitación Son benchmarks, no despliegues reales. El modelo predictivo explica una parte modesta de la varianza (R² de 0,373). Cifras de versiones anteriores, como una amplificación de errores de hasta 17,2 veces, no se verificaron en la versión 3 y no se usan.
Las 60 rondas del principio tienen una causa probable: un agente no es buen juez de su propio trabajo. Anthropic lo dice en su post sobre arneses: “agents reliably skew positive when grading their own work”. Al calificarse, los agentes son demasiado generosos.
El evaluador separado de su arnés también fallaba. Anduvo cuando lo afinaron para ser escéptico y para probar el resultado con una herramienta externa, en lugar de leerlo.
Dos agentes que se revisan entre sí sin un árbitro pueden seguir dando vueltas. OWASP es una fundación de seguridad.
Su lista de riesgos para aplicaciones con agentes (la prueba 33) incluye las fallas en cascada: un error que pasa de un agente a otro. Es uno de sus diez riesgos.
Como mitigación, pide controles fuera del modelo y topes de costo, de tasa o de tokens con corte automático. Su lista es un marco voluntario: no obliga a nadie ni mide nada.
Dos agentes que se revisan entre sí terminan corrigiéndose solos.
Veredicto: Solo si algo fuera de los dos decide cuándo parar y qué cuenta como terminado. Según la empresa que lo vende, un agente revisor con contexto limpio encuentra en promedio 2 errores por pull request. Pero los agentes que se califican solos son demasiado generosos. El evaluador separado fallaba hasta que lo afinaron para probar con una herramienta externa. En otro equipo, dos agentes se consultaron 60 rondas sin resultado.
Criterio
Poné en código un máximo de rondas, un tope de gasto y un registro de llamadas que corte las repetidas. Que el criterio de terminado lo defina el sistema, no los agentes.
Por qué confianza media. Los casos con más detalle, a favor y en contra, los publican empresas que venden agentes o modelos. Usan datos propios y no tienen grupo de control. El bucle de 60 rondas es un comentario en un hilo chico de Reddit. OWASP pone las fallas en cascada entre los diez riesgos de los agentes, pero no las mide.
Ver el detalle de las 4 pruebasOcultar el detalle1 a favor, 2 en contra, 1 matiza
El autor desaconsejó los sistemas multiagente y diez meses después revisa su postura. Para él, varios agentes que escriben en paralelo todavía toman decisiones incompatibles, pero tres patrones sí funcionan. Son un revisor con contexto limpio, un modelo chico que consulta lo difícil a uno más fuerte y un agente gerente que reparte trabajo. En los tres, un solo hilo escribe.
Números
2 errores por pull requestPromedio que encuentra el agente revisor; cerca de 58 % son graves.
unas 8 vecesCrecimiento del uso de su agente en el segmento de empresas más grande, en 6 meses.
Limitación Lo publica una empresa que vende un agente de código; los números son internos.
“clean context leads to a notable improvement in capabilities”
Compara un agente solo con un arnés de tres agentes (planificador, generador y evaluador) para construir aplicaciones completas. El arnés dio resultados claramente mejores, pero costó más de 20 veces. Los agentes que se califican a sí mismos son demasiado generosos. El evaluador separado también fallaba hasta que lo afinaron para ser escéptico y probar con una herramienta externa. Cada pieza del arnés supone algo que el modelo no puede hacer solo, y con un modelo mejor (Opus 4.6) sacaron piezas.
Números
20 minutos y 9 dólares contra 6 horas y 200 dólaresUn juego retro con Opus 4.5: agente solo (el juego no respondía a los controles) contra arnés completo (jugable).
3 horas 50 minutos y 124,70 dólaresUna estación de audio digital con Opus 4.6 y el arnés simplificado.
Limitación Casos propios del proveedor, sin grupo de control sistemático.
“agents reliably skew positive when grading their own work”
Una persona dice que construyó más de 150 agentes para negocios. Cuenta que los que funcionaron eran simples, de un solo propósito y con una persona para una parte chica de la tarea. En los comentarios, otro equipo cuenta que dos agentes se consultaron entre sí 60 rondas sin resultado. El costo subía hasta que agregaron una capa que corta las llamadas repetidas.
Números
más de 150 agentesAgentes que el autor dice haber construido en un año (autoinformado).
60 rondasBucle entre dos agentes sin resultado útil, según un comentario.
Limitación Hilo chico (9 puntos y 12 comentarios en el archivo). Cifras autoinformadas. Se leyó en el archivo público Arctic Shift porque reddit.com bloquea la lectura automática. La cita se comparó letra por letra con el original.
“simple, single-purpose, and had a human-in-the-loop for 5% of the task”
Es la primera lista de consenso de OWASP hecha para agentes. Los diez riesgos van desde el secuestro del objetivo del agente (ASI01) hasta los agentes rebeldes (ASI10). Entre ellos están el mal uso de herramientas (ASI02) y el abuso de identidad y privilegios (ASI03). También están la cadena de suministro agéntica (ASI04) y las fallas en cascada (ASI08). Suma el principio de mínima agencia: no dar autonomía que no hace falta. Como mitigaciones pide perfiles de mínimo privilegio por herramienta, aprobación humana para acciones destructivas y controles fuera del modelo. También pide topes de costo, tasa o tokens con corte automático.
Números
10 riesgos (ASI01 a ASI10)Tamaño de la lista. ASI02 y ASI03 extienden la agencia excesiva (LLM06) de la lista de 2025 a flujos de varios pasos.
Limitación Es un marco voluntario de consenso: no obliga a nadie y no mide nada. En la lista de agentes, el consumo sin límites ya no es un ítem propio: aparece como escenario y mitigación dentro de ASI02. Se leyó el PDF completo (57 páginas).
“deploying agentic behavior where it is not needed expands the attack surface”
Varios agentes rinden más cuando la tarea se reparte en partes independientes.Rinden menos cuando cada paso depende del anterior. En los dos casos cuestan más que uno solo.
Queda la salida más tentadora: esperar un modelo mejor. Ayuda en algo. Con Opus 4.6, Anthropic pudo sacar piezas de su arnés.
Con ese arnés más simple, construyó una estación de audio digital en 3 horas 50 minutos y por 124,70 dólares.
Pero el experimento del compilador, del mismo proveedor (la prueba 52), muestra el límite. Dieciséis agentes trabajaron en paralelo. Se coordinaron solo con un repositorio compartido y archivos para reclamar tareas.
Escribieron un compilador de C de unas 100.000 líneas, por poco menos de 20.000 dólares. Funcionó mientras el trabajo se partía en piezas independientes con un verificador externo.
unas 100.000 líneas
Tamaño del compilador de C en Rust. Compila Linux 6.9 en x86, ARM y RISC-V con 99 % de aprobación en la mayoría de las suites. Prueba 52
Después atacaron el kernel de Linux como una sola tarea grande. Todos los agentes encontraban el mismo error, lo arreglaban y se pisaban los cambios.
El modelo era el mismo en los dos casos. Cambió la forma de la tarea.
Un modelo mejor ayuda dentro de cada agente, pero no reparte las tareas ni verifica el resultado. Eso lo decide quien diseña el sistema. El mismo proveedor lo dice en otro post (la prueba 77): el arnés codifica supuestos que vencen con cada modelo nuevo.
Por eso separa las piezas con interfaces estables, es decir, puntos de conexión que no cambian. Así cambia una pieza sin perder el resto.
La comparación de Google muestra que la arquitectura se puede elegir con criterio. Su modelo predictivo eligió la mejor arquitectura en 87 % de las configuraciones de prueba.
Ese modelo explica una parte modesta de la varianza (las diferencias entre resultados). Sirve como guía, no como regla.
Si el sistema multiagente falla, es porque el modelo todavía no es lo bastante bueno.
Veredicto: Un modelo mejor ayuda, pero no arregla el diseño. Con un modelo más nuevo, un proveedor pudo sacar piezas de su arnés de tres agentes. El arnés es el código que rodea y guía a los agentes. Pero dieciséis agentes atacaron el kernel de Linux como una sola tarea grande. Todos encontraban el mismo error y se pisaban los cambios. En una comparación controlada, coordinar varios agentes ayudó en tareas que se pueden descomponer. En las secuenciales, dañó.
Criterio
Antes de cambiar de modelo, leé las trazas y clasificá cada falla: diseño, coordinación entre agentes o verificación. Elegí la arquitectura por la forma de la tarea, no por la moda.
Por qué confianza media. La comparación controlada es amplia, pero sobre benchmarks, y su modelo predictivo explica una parte modesta de la varianza. Los casos del compilador y del arnés son experimentos de un proveedor con su propio modelo, sin grupo de control.
Ver el detalle de las 4 pruebasOcultar el detalle1 a favor, 2 en contra, 1 matiza
Compara un agente solo con un arnés de tres agentes (planificador, generador y evaluador) para construir aplicaciones completas. El arnés dio resultados claramente mejores, pero costó más de 20 veces. Los agentes que se califican a sí mismos son demasiado generosos. El evaluador separado también fallaba hasta que lo afinaron para ser escéptico y probar con una herramienta externa. Cada pieza del arnés supone algo que el modelo no puede hacer solo, y con un modelo mejor (Opus 4.6) sacaron piezas.
Números
20 minutos y 9 dólares contra 6 horas y 200 dólaresUn juego retro con Opus 4.5: agente solo (el juego no respondía a los controles) contra arnés completo (jugable).
3 horas 50 minutos y 124,70 dólaresUna estación de audio digital con Opus 4.6 y el arnés simplificado.
Limitación Casos propios del proveedor, sin grupo de control sistemático.
“agents reliably skew positive when grading their own work”
Dieciséis instancias de Claude trabajaron en paralelo, sin un orquestador que repartiera el trabajo. Se coordinaron solo con un repositorio git compartido y archivos de bloqueo para reclamar tareas. Funcionó mientras el trabajo se podía partir en piezas independientes con un verificador externo (GCC y suites de tests). Encararon el kernel de Linux como una sola tarea grande. Ahí todos los agentes encontraban el mismo error, lo arreglaban y se pisaban los cambios.
Números
casi 2.000 sesiones y poco menos de 20.000 dólaresSesiones de Claude Code en dos semanas y costo en API (2.000 millones de tokens de entrada y 140 millones de salida, Opus 4.6).
unas 100.000 líneasTamaño del compilador de C en Rust. Compila Linux 6.9 en x86, ARM y RISC-V con 99 % de aprobación en la mayoría de las suites.
Limitación Un experimento del proveedor. El código generado es menos eficiente que GCC sin optimizaciones. La tarea tenía un verificador externo muy bueno, algo que pocos procesos de empresa tienen.
Kim, Y., Gu, K., Park, C., et al. arXiv (Google y otros)
Es una comparación controlada y amplia entre un agente único y cuatro arquitecturas multiagente. El resultado depende de cómo es la tarea: coordinar varios agentes ayuda si la tarea se divide en partes y daña si es secuencial. Las arquitecturas sin verificación central propagan más errores.
Números
260 configuracionesCombinaciones de 6 benchmarks, 5 arquitecturas y 3 familias de modelos.
de +80,8 % a -70,0 %Cambio frente al agente único: de razonamiento financiero descomponible a planificación secuencial.
87 %Configuraciones de prueba donde su modelo elige la mejor arquitectura.
Limitación Son benchmarks, no despliegues reales. El modelo predictivo explica una parte modesta de la varianza (R² de 0,373). Cifras de versiones anteriores, como una amplificación de errores de hasta 17,2 veces, no se verificaron en la versión 3 y no se usan.
Separa tres piezas con interfaces estables: la sesión, el arnés y el sandbox. La sesión es un registro de eventos fuera del contexto. El arnés es el bucle que llama al modelo y el sandbox corre el código. Así cualquier pieza puede fallar o cambiarse sin perder la sesión, y las credenciales quedan fuera del sandbox. Repite que el arnés codifica supuestos que vencen con cada modelo nuevo.
Números
cerca de 60 % y más de 90 %Baja del tiempo hasta el primer token en la mediana (p50) y en el percentil 95.
Limitación Post de producto del proveedor. No compara flujo fijo contra agente.
Empezá con un solo agente. Repartí el trabajo solo si la forma de la tarea lo pide y la mejora medida paga el costo extra. En la práctica:
Mirá la forma de la tarea antes que la moda. Si las partes son independientes, varios agentes pueden ganar. Si se encadenan, uno solo rinde más.
Usá subagentes para buscar, resumir o revisar, no para escribir en paralelo. Lo que se escribe queda en un solo hilo, y el estado compartido vive en archivos, fuera del contexto.
Poné en código un máximo de rondas, un tope de gasto y un registro de llamadas que corte las repetidas. El sistema decide cuándo está terminado el trabajo, no los agentes.
Antes de cambiar de modelo, leé las trazas y clasificá cada falla: diseño, coordinación entre agentes o verificación. Una traza es el registro completo de lo que hizo el sistema, paso por paso.
Ahora, según tu caso:
Si ya tenés un sistema con varios agentes, abrí las trazas de las últimas corridas que fallaron. Anotá en cada una la categoría de la falla. Si la mayoría es de coordinación o de verificación, un modelo nuevo no la va a arreglar.