Lección 2: Orquestador y subagentes: repartir y agregar

Objetivos de aprendizaje:

• Enunciar de qué es responsable el orquestador y de qué son responsables los subagentes en una arquitectura orquestador-subagente
• Explicar qué aísla en realidad el «aislamiento de contexto», y por qué alivia la contaminación de contexto y la dilución de la atención de la lección anterior
• Explicar por qué un subagente debería devolver al orquestador solo su conclusión, en lugar de volcar de vuelta todo su hilo de pensamiento acumulado

Requisitos: Terminar la Lección 1 y entender la definición de «sistema multiagente» y dónde encaja | Anterior: Lección 1 << | Siguiente: Lección 3 >>

El orquestador: partir la tarea, repartirla, esperar los resultados

La lección pasada decidimos que una tarea como «investigar los precios de tres proveedores de nube» encaja bien con repartirla entre varios agentes, pero nunca detallamos cómo funciona ese reparto en realidad. Una estructura habitual para ello es la arquitectura orquestador-subagente. La definición oficial es "a central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results."¹ (un LLM central descompone dinámicamente las tareas, las delega a LLM trabajadores y sintetiza sus resultados).

Esa definición nombra tres acciones, y se corresponden con las tres cosas que hace el orquestador: descomponer —mirar una tarea grande y averiguar en qué trozos se parte—; delegar —entregar cada trozo, junto con el trasfondo que necesita, a un subagente para que lo lleve a cabo—; sintetizar —una vez que los subagentes han devuelto sus resultados, combinarlos en la respuesta final—. El orquestador mismo nunca baja a leer la página de precios de un proveedor. Su trabajo es decidir cómo dividir el trabajo, quién recibe qué, y cómo coser varios resultados en una respuesta que se sostenga como un todo.

El subagente: tomar una tarea, terminarla dentro de su propio contexto

Del lado del subagente, las cosas funcionan de forma bastante distinta. La documentación es explícita: "Each subagent starts with a fresh, isolated context window. It doesn't see your conversation history, the skills you've already invoked, or the files Claude has already read. Claude composes a delegation message that summarizes the task, and the subagent works from there."² (cada subagente arranca con una ventana de contexto fresca y aislada; no ve tu historial de conversación, las skills que ya has invocado ni los archivos que Claude ya ha leído; Claude compone un mensaje de delegación que resume la tarea, y el subagente trabaja a partir de ahí). Dicho de otro modo, un subagente no tiene ni idea de qué le dijiste primero al orquestador, ni de cómo el orquestador sopesó internamente «¿deberíamos partir esto?» y «¿en cuántas piezas?». Todo lo que puede ver es el único informe de tarea que el orquestador le entregó.

Esto parece una limitación, pero en realidad es la cura para los dos problemas de la lección pasada. El contexto del subagente no arrastra el historial completo de conversación del orquestador, así que tampoco arrastra los callejones sin salida en los que el orquestador se metió en otra parte ni el material irrelevante que vio. Eso es el aislamiento de contexto: confinar el ámbito de trabajo de cada agente a su propia ventana de contexto, de modo que la contaminación de contexto dentro de un agente no se propague a otro. El subagente sostiene solo el material de su propia porción de la tarea, y no tiene que hacer malabares con todo el contenido de tres empresas a la vez, así que la presión de la dilución de la atención también baja. En cuanto a cómo escribir un informe de tarea lo bastante claro como para que un subagente pueda hacer buen trabajo por su cuenta sin ver jamás el historial de conversación, eso es la siguiente lección.

Repartir (fan-out): partir la tarea y entregarla a varios subagentes a la vez

Volvamos al ejemplo de los precios de tres proveedores. Una vez que el orquestador ha descompuesto el trabajo en «comprobar el primero», «comprobar el segundo», «comprobar el tercero», no los pone en cola uno a uno. Los reparte todos a la vez, que es exactamente lo que hace el sistema en producción: el agente líder pone en marcha de 3 a 5 subagentes en paralelo en lugar de en serie³. Ese movimiento de «repartirlo todo al mismo tiempo» es el repartir (fan-out): el orquestador distribuye en paralelo las subtareas ya partidas a un número equivalente de subagentes, dejando que cada uno empiece a trabajar de forma independiente y simultánea, en lugar de esperar a que el primer subagente termine antes de despachar el segundo.

El beneficio del repartir es directo: tres subagentes trabajando en paralelo significa que el tiempo total se acerca al de hacer una sola pieza de investigación, no a la suma de tres. Después de que el sistema en producción introdujo esta clase de paralelización, el tiempo de investigación en consultas complejas bajó hasta un 90%³. Pero repartir no es solo trocear la tarea y darla por hecha: cómo cortas importa. Tres empresas son naturalmente independientes, así que cortar en tres encaja limpiamente. Cambia a «revisar un contrato de 20 páginas» y las cláusulas pueden referenciarse y condicionarse entre sí; un mal corte deja a cada subagente sin contexto clave, llegando a conclusiones que se contradicen entre ellas. Decidir cómo y con qué finura cortar vuelve a la prueba de la lección pasada: ¿cada trozo que recortas es de verdad algo que se puede manejar por su cuenta, sin depender de los resultados intermedios de otro trozo?

Agregar: juntar los resultados, no solo pegarlos

Después de que los tres subagentes terminan cada uno de comprobar los precios de su propia empresa y devuelven los resultados, lo que hace el orquestador no es pegar tres bloques de texto uno tras otro. Lo que los subagentes devuelven son conclusiones de investigación desde sus propios puntos de vista, y el trabajo del orquestador es agregar: poner varios resultados producidos de forma independiente uno al lado del otro, compararlos, resolver la duplicación o contradicción que aparezca, y reorganizarlos en la forma del entregable final, escribiendo un documento que se lea como un todo, no como tres piezas cosidas de forma evidente.

La documentación, al describir cómo los subagentes hacen la entrega en secuencia, señala que "Each subagent completes its task and returns results to Claude, which then passes relevant context to the next subagent."² (cada subagente completa su tarea y devuelve resultados a Claude, que luego pasa el contexto relevante al siguiente subagente). Así que la agregación no es necesariamente tan simple como «esperar a que cada subagente entregue su trabajo, y luego el orquestador lo recoge todo de una vez y lo procesa». En algunos casos el resultado del subagente anterior es en sí parte del informe de tarea del siguiente subagente, y el orquestador va y viene entre repartir y agregar hasta que cada subtarea tiene un resultado.

El camino que recorre un resultado tampoco tiene que pasar siempre por el orquestador. Cuando el contenido que un subagente produce es grande y hay que mantenerlo intacto, la documentación menciona un enfoque: "Subagent output to a filesystem to minimize the 'game of telephone.' Direct subagent outputs can bypass the main coordinator for certain types of results, improving both fidelity and performance."³ (que el subagente escriba su salida a un sistema de archivos para minimizar el «teléfono descompuesto»; las salidas directas del subagente pueden saltarse el coordinador principal para ciertos tipos de resultado, mejorando tanto la fidelidad como el rendimiento). Escribir directo al sistema de archivos es, en el fondo, una forma de evitar que un resultado sea parafraseado, comprimido y pierda detalle a lo largo de la cadena «subagente → orquestador → salida final».

Devolver solo la conclusión, no todo el hilo de pensamiento del subagente

Para terminar su tarea, un subagente puede leer por el camino muchas páginas de material irrelevante, probar unos cuantos caminos que no llevan a nada, incluso cometer pequeños errores y corregirse. Ese proceso no necesita —ni debería— volver a meterse tal cual en el contexto del orquestador. Lo que el orquestador necesita es la conclusión final y defendible del subagente y la evidencia clave que la respalda, no todo el rastro de razonamiento con sus rodeos.

La razón vuelve al punto de la Lección 1: el orquestador tiene una ventana de contexto propia, y pasa también por contaminación de contexto y dilución de la atención. La documentación es directa al respecto: cuando los subagentes terminan, sus resultados vuelven a la conversación principal, y ejecutar muchos subagentes que devuelven cada uno resultados detallados puede consumir un contexto considerable². Si tres subagentes vuelcan de vuelta tal cual varios miles de palabras de razonamiento completo, el orquestador acaba encontrándose, en su propia capa, con el mismísimo problema que se suponía que varios agentes iban a aliviar. El devolver debería llevar solo la conclusión en sí, y dejar el detalle de «cómo llegué ahí» en el propio contexto del subagente, que ya ha gastado y está a punto de descartar.

Esto no significa que cada delegación arranque desde cero. La documentación menciona un tipo especial de subagente —un fork—: "A fork is a subagent that inherits the entire conversation so far instead of starting fresh... The fork's own tool calls still stay out of your conversation and only its final result comes back, so your main context window stays clean."² (un fork es un subagente que hereda toda la conversación hasta ahora en lugar de arrancar de cero; las propias llamadas a herramientas del fork siguen quedándose fuera de tu conversación y solo vuelve su resultado final, así que tu ventana de contexto principal se mantiene limpia). Así que incluso cuando un subagente sí necesita en algún caso raro ver el historial completo (digamos que tiene que producir un resumen profundo apoyado en toda la discusión previa), su pensamiento intermedio sigue sin entrar tal cual en el contexto del orquestador. El principio de «devolver solo la conclusión» es estable; lo único que cambia es si el subagente arranca con el historial en la mano.

Dicho de otro modo: la misma división del trabajo aparece en otros marcos

«Orquestador-subagente» no es la fórmula privada de un solo proveedor. La documentación del Agents SDK de OpenAI llama a la misma estructura el patrón Manager: "A central manager/orchestrator invokes specialized sub‑agents as tools and retains control of the conversation."⁴ (un manager/orquestador central invoca subagentes especializados como herramientas y retiene el control de la conversación). Cambia las palabras —manager por orquestador, agentes-como-herramientas por subagentes— y describe lo mismo: un nodo central descompone la tarea, reparte el trabajo y mantiene el control del conjunto, mientras que la ejecución real recae en subordinados especializados que devuelven sus resultados, y el nodo central sigue dirigiendo lo que viene después. Reconocer la forma de esta división del trabajo importa más que memorizar la terminología de un marco concreto: verás alguna variante de esta lógica en la documentación de casi cualquier marco multiagente.

Resumen

• En la arquitectura orquestador-subagente, un LLM central descompone la tarea, delega subtareas a varios LLM trabajadores y sintetiza sus resultados¹; el orquestador mismo no baja a manejar el contenido detallado de una subtarea.
• Cada subagente arranca por defecto desde una ventana de contexto fresca y aislada y no puede ver el historial de conversación del orquestador²: esto es el aislamiento de contexto, el mecanismo clave para aliviar la contaminación de contexto y la dilución de la atención de la lección pasada.
• El repartir (fan-out) distribuye en paralelo las subtareas ya partidas a varios subagentes para que trabajen a la vez; agregar no es un simple pegado de las respuestas de los subagentes sino un paso de comparar, resolver contradicciones y reorganizar a un formato único; y el paso de resultados también puede saltarse el orquestador y escribir directo al sistema de archivos, para reducir la información perdida en la paráfrasis³.
• Después de que un subagente termina, su resultado vuelve al orquestador²; lo que se devuelve debería ser solo la conclusión, no los rodeos con los que se topó ni todo su hilo de pensamiento; la documentación es explícita en que muchos subagentes que devuelven cada uno resultados detallados pueden consumir un contexto considerable², y el orquestador se encontraría con la contaminación de contexto y la dilución de la atención otra vez en su propia capa.
• «Orquestador-subagente» no es la fórmula privada de un marco: el Agents SDK de OpenAI llama a la misma estructura el patrón Manager, un manager central que invoca subagentes como herramientas mientras retiene el control de la conversación⁴. Reconocer la lógica compartida detrás de esta división del trabajo importa más que memorizar cualquier término concreto.

>> Lección 3: Escribir prompts para delegar