Claude aprende a lanzar hasta 1000 subagentes y encuentra 66 de 70 bugs

Anthropic añade workflows dinámicos a Claude Managed Agents: el agente líder puede repartir tareas entre subagentes, y hasta 1000 de ellos pueden trabajar a la vez. La cifra principal de la versión sale de una prueba con una base de código que contenía 70 bugs escondidos de antemano. El agente individual encontraba como máximo 27; el workflow multiagente llegaba de forma estable a 66. Es aproximadamente un 94% frente a un 39%.

Cómo funciona

El esquema tiene dos niveles. El agente líder analiza la tarea, decide cómo dividirla y envía los fragmentos a los subagentes. Estos trabajan en paralelo y devuelven los resultados al líder. A juzgar por el nombre, el desarrollador no define de antemano la estructura del workflow, sino que se construye sobre la marcha, a medida que avanza la tarea. Eso distingue este enfoque de los pipelines rígidos, en los que el número de pasos y su orden se conocen antes de la ejecución.

La función forma parte de Claude Managed Agents, es decir, de la plataforma gestionada para agentes. Al parecer, Anthropic se encarga aquí de la infraestructura de ejecución y coordinación, en lugar del equipo que escribe su propio orquestador.

Parámetros clave del anuncio:

• límite superior: 1000 subagentes trabajando a la vez;
• papel del líder: descomponer la tarea y repartir las subtareas;
• tarea de prueba: encontrar 70 bugs ocultos en una base de código;
• agente individual: un máximo de 27 errores encontrados (en torno al 39%);
• workflow multiagente: 66 de forma estable (en torno al 94%);
• diferencia: 2,4 veces más bugs encontrados.

Qué mostró la prueba

La palabra «estable» es importante. Si el esquema multiagente hubiera ganado una sola vez, se podría atribuir a una ejecución afortunada. Aquí el resultado se repitió, mientras que el agente individual se quedó en 27 incluso en su mejor intento.

Por qué el paralelismo ayuda precisamente en la búsqueda de bugs se puede explicar sin magia. Una base de código grande no cabe entera en la atención de trabajo de un solo agente. Este revisa una parte de los archivos, extrae conclusiones y se desvía. Cuando cada subagente recibe un tramo acotado y responde solo de él, la cobertura aumenta. Los cuatro bugs de 70 que no se detectaron muestran, no obstante, que sigue habiendo un techo.

Las salvedades son evidentes. Se trata de una sola prueba, y la planteó la propia compañía. En el material de The Decoder no hay datos sobre el coste de una ejecución así, el tiempo que requiere ni el número de falsos positivos. Para la búsqueda de bugs, este último indicador es crítico: 66 problemas encontrados valen poco si vienen acompañados de otros 200 inventados. Tampoco se ha revelado hasta qué punto el resultado es extrapolable a otras tareas.

Cómo abordar la adopción

No conviene empezar con mil agentes. Lo más sensato es elegir una tarea que se divida de forma natural en partes independientes y comparar una ejecución individual con otra multiagente sobre datos propios.

Candidatas adecuadas: auditoría de un repositorio, búsqueda de vulnerabilidades, generación de tests por módulos, verificación de la migración a una nueva versión de una biblioteca, análisis de un gran volumen de documentos. Encajan peor las tareas en las que los pasos dependen estrictamente unos de otros: el paralelismo apenas aportará nada.

Antes de escalar conviene medir tres cosas: el coste por cada bug confirmado, la proporción de falsos hallazgos y el tiempo hasta tener el informe listo. Además, hacen falta un presupuesto y un límite al número de subagentes; de lo contrario, la factura llegará antes que el resultado. La verificación final de los hallazgos es mejor dejarla en manos de una persona o de un agente verificador independiente, en lugar de dar por bueno el informe del líder.