El orquestador y los subagentes

El patrón del orquestador y los subagentes (en inglés, orchestrator-workers) es la forma de organizar un sistema de inteligencia artificial en la que un agente principal no hace el trabajo, sino que lo reparte. Recibe la tarea, la divide en partes, lanza para cada parte un subagente con sus propias instrucciones y su propio contexto, espera sus resultados y los combina. Cada subagente es a su vez un bucle ReAct completo, con sus herramientas y su límite de pasos, pero empieza con la memoria limpia y termina devolviendo un resumen. La idea es tan vieja como la gestión de proyectos. Lo que la ha convertido en uno de los debates técnicos más vivos de 2025 es que dos de los equipos que más saben de agentes publicaron, con un día de diferencia, conclusiones opuestas sobre si conviene usarla.

El 12 de junio de 2025, Walden Yan, de Cognition, la empresa del agente de programación Devin, publicó un texto titulado sin rodeos No construyas sistemas de varios agentes. Al día siguiente, un equipo de Anthropic describió cómo había construido la función de investigación de su asistente precisamente con varios agentes, y dio cifras de por qué. Los dos textos tienen razón, y leerlos juntos es la mejor manera de entender cuándo el patrón funciona.

El argumento a favor es de capacidad y de contexto. El sistema de Anthropic usaba un modelo grande como orquestador y modelos medianos como subagentes, y en la evaluación interna de la empresa, preguntas de investigación que exigían consultar muchas fuentes, superaba en un 90,2 por ciento al mismo modelo grande trabajando solo. El análisis de por qué es la parte más útil del texto. En un banco de pruebas público de búsqueda de información difícil, tres factores explicaban el 95 por ciento de las diferencias de rendimiento entre configuraciones, y uno solo, la cantidad de tokens consumidos, explicaba el 80 por ciento. Dicho llano: los sistemas de varios agentes funcionaban mejor sobre todo porque leían más, y podían leer más porque cada subagente tenía su propia ventana de contexto en lugar de compartir una. El coste de eso también está en el texto: un agente consume unas cuatro veces los tokens de una conversación, y el sistema de varios agentes, unas quince.

La figura muestra el mecanismo que hay debajo de esas cifras. Un solo agente que hace seis subtareas de treinta mil tokens cada una termina con casi doscientos mil tokens en la conversación, y cada paso de la última subtarea arrastra la lectura completa de las cinco primeras, aunque ya no le sirva de nada. Repartidas, ningún subagente pasa de unos cuarenta y cinco mil, y el orquestador trabaja con seis resúmenes. Si se hace exactamente el mismo trabajo, el reparto incluso reduce el total leído, porque evita la relectura cuadrática de un bucle muy largo. En la práctica el total sube, y por dos razones que la figura permite ver por separado. Los subagentes, al tener sitio, exploran más: el quince frente a cuatro de Anthropic no mide el mismo trabajo hecho de otra forma, sino un trabajo más amplio. Y repiten: sin ver lo que hacen los demás, dos subagentes leen la misma fuente o prueban la misma búsqueda.

El argumento en contra es de coherencia, y es el de Cognition. Yan lo formula en dos principios. El primero: compartir el contexto entero, las trazas completas de lo que cada agente hizo y no solo sus mensajes finales. El segundo, más sutil: las acciones llevan decisiones implícitas, y las decisiones en conflicto producen malos resultados. Su ejemplo es un encargo para construir un clon del juego Flappy Bird repartido entre dos subagentes, uno para el fondo y otro para el pájaro. Uno interpreta la tarea y dibuja un fondo al estilo de Super Mario; el otro dibuja un pájaro que no encaja con ese fondo ni se mueve como en el original, y el orquestador tiene que casar dos piezas que nunca debieron hacerse por separado. Ninguno de los dos se equivocó según sus propias instrucciones. Lo que falló es que cada uno tomó decenas de pequeñas decisiones de estilo que el otro no podía ver. La alternativa que propone es un único agente lineal y, para tareas que desbordan la ventana, un modelo dedicado a comprimir la historia.

La lectura conjunta la hace el propio texto de Anthropic en una frase que suele citarse menos que su 90,2 por ciento: la mayoría de las tareas de programación tienen menos partes verdaderamente paralelizables que la investigación, y los dominios en los que todos los agentes necesitan compartir el mismo contexto o hay muchas dependencias entre ellos no son hoy un buen terreno para el patrón. La investigación funciona porque sus partes son independientes. Averiguar la historia de una empresa, su situación financiera y sus litigios pendientes son tres búsquedas que no se estorban y cuyos resultados se combinan leyendo. Construir un programa es lo contrario: cada decisión sobre una parte condiciona las demás. La regla que se deduce es la misma que rige para repartir trabajo entre personas. Se reparte lo que no necesita leer el resultado de lo otro.

Hay una forma más modesta del patrón que casi todos los agentes de programación actuales usan y que no despierta ningún debate: el subagente como herramienta de lectura. Cuando el agente principal necesita saber dónde se define una función en un repositorio de diez mil ficheros, lanza un subagente que busca, lee lo que haga falta y devuelve tres líneas con la respuesta. Los cien mil tokens de búsqueda no entran nunca en la conversación principal. La guía de Anthropic sobre ingeniería de contexto de septiembre de 2025 lo describe así, con subagentes que devuelven un resumen destilado de su trabajo, a menudo de entre mil y dos mil tokens. Es la misma idea que el código como acción: lo que el modelo principal no necesita leer, que no lo lea.

Cuando el patrón falla, falla de maneras que ya están catalogadas. Mert Cemri y sus coautores de la Universidad de California en Berkeley anotaron en 2025 más de mil seiscientas trazas de siete marcos de trabajo de varios agentes, con un acuerdo entre anotadores muy alto. Agruparon los fallos en catorce modos y tres familias: problemas de diseño del sistema, como papeles mal definidos o pasos que se repiten; desalineación entre agentes, como uno que ignora lo que otro le dijo o que retiene información que el otro necesitaba; y fallos de verificación, como dar por terminada una tarea que no lo está. La observación de partida del estudio es la que conviene recordar antes de dibujar un organigrama de agentes: en los bancos de pruebas habituales, las ganancias de estos sistemas frente a un solo agente bien construido son a menudo mínimas.

Lo que queda, después del debate, es un criterio de tres preguntas. Si las partes de la tarea son independientes, el patrón compra capacidad a cambio de tokens, y la compra suele merecer la pena cuando el valor de la respuesta es alto. Si las partes dependen unas de otras, el patrón convierte cada dependencia en un malentendido potencial, y un solo agente con buena gestión de su contexto suele ganar. Y en ambos casos, antes de repartir nada, hay que tener una forma de medir si el reparto ha mejorado algo, porque orquestar agentes sin evaluarlos es multiplicar un número que no se conoce.