Lección 4: Orquestador-trabajadores: volver dinámica la descomposición misma

Objetivos de aprendizaje:

• Definir orquestador-trabajadores y articular la diferencia clave frente a la paralelización: topográficamente parecidos, pero las subtareas no vienen predefinidas—el orquestador las decide según la entrada concreta
• Equipar cada despacho con los cuatro elementos (objetivo, formato de salida, guía sobre herramientas y fuentes, límites de la tarea), y escribir en el prompt las reglas de escalado («cuántos lanzar, cuánto puede gastar cada uno»)
• Leer un balance completo de un sistema real en producción: dónde aparece la mejora del 90,2 %, por qué la factura de 15× es la otra mitad del mismo mecanismo, qué bloquea la ejecución síncrona, y qué tres costos nuevos te obliga a cargar la asincronía

Requisitos: Lecciones 1–3 completadas (esta lección retoma la pregunta que quedó sin responder al final de la Lección 3) | Anterior: << Lección 3 | Siguiente: Lección 5 >>

El hueco que dejó abierto la Lección 3

En la Lección 3 escribiste seccionamiento: partir una tarea en subtareas independientes, ejecutarlas a la vez, y luego agregar los resultados con código. Vuelve a mirar ese código—¿dónde vive la lógica de la partición? Está en el arreglo que codificaste a mano: SECTIONS = ['security', 'performance', 'readability']. Las tres ramas quedaron decididas cuando escribiste el código; el tiempo de ejecución apenas las ejecuta.

Este enfoque funciona bajo una suposición rígida: ya sabes en tiempo de escritura cómo dividir la tarea. La revisión de código encaja en esa suposición porque las dimensiones de revisión son estables—cambias de repositorio y sigues revisando los mismos aspectos.

Ahora considera una tarea distinta:

«Investiga los problemas de rendimiento de este código base.»

¿Cuántas piezas? ¿Cuáles piezas? No lo puedes codificar a mano. Tal vez el cuello de botella esté en las consultas a la base de datos, así que despacharías a alguien a escanear los sitios de llamada del ORM. Tal vez esté en un bucle de ruta caliente, así que mandarías a alguien a leer la salida del profiler. Tal vez sea el tamaño del artefacto de compilación, sin relación con el tiempo de ejecución. Qué archivos cambiar, qué direcciones investigar—tienes que mirar este repositorio concreto, esta descripción concreta del problema, antes de saberlo.

Dicho de otro modo: la descomposición misma debe computarse en tiempo de ejecución. Tu código ya no guarda la decisión de «en qué piezas partirlo»; solo guarda el mecanismo de «cómo despachar, cómo recolectar, cómo sintetizar». ¿Quién toma esa decisión? Un LLM.

Ese es el cuarto patrón.

Definición, y en qué se diferencia de la paralelización

La fuente oficial da una definición de una sola frase: en el flujo de trabajo orquestador-trabajadores, un LLM central descompone dinámicamente las tareas, las delega a LLM trabajadores y sintetiza sus resultados¹.

Tres acciones: descomponer, delegar, sintetizar. La del medio—delegar—ya la escribiste en la Lección 3; el código de fan-out es casi idéntico. Lo verdaderamente nuevo es la primera acción: la descomposición pasa del código a manos del modelo.

El enunciado de caso de uso es más preciso: este flujo de trabajo encaja bien con tareas complejas en las que no puedes predecir las subtareas necesarias; el ejemplo oficial es la programación—la cantidad de archivos que hay que cambiar y la naturaleza de cada cambio probablemente dependen de la tarea misma¹.

Después viene la comparación que debes recordar. La fuente dice: aunque es topográficamente similar a la paralelización, la diferencia clave es la flexibilidad—las subtareas no vienen predefinidas, sino que las determina el orquestador según la entrada concreta¹.

El término que usa es "topographically similar" (topográficamente similar): parecidos en forma. Vale la pena detenerse en esta formulación. Si diagramas el seccionamiento de la Lección 3 y el orquestador-trabajadores de esta lección, dibujarás formas casi idénticas: un nodo se abre en abanico hacia tres, que después colapsan de vuelta en uno. La forma engaña. La diferencia no está en el diagrama; está en cuándo se toma esa decisión:

Esa última fila es donde está el dolor de ingeniería. Con seccionamiento, el prompt de cada rama es artesanal; puedes iterarlo y afinarlo, agregar ejemplos para cada dimensión. Orquestador-trabajadores no puede hacer eso—los prompts de despacho los genera el orquestador sobre la marcha, y tú solo controlas las reglas que sigue al generarlos. Las dos secciones siguientes explican qué deberían contener esas reglas.

Primero, escribamos el mecanismo como un esqueleto. El código de abajo es una ilustración propia de esta lección; no existe ningún script de orquestación oficial en los materiales primarios, así que no lo tomes como una implementación estándar:

Compara esto línea por línea con el código de fan-out de la Lección 3; verás que solo se agregó el paso 1. Ese paso agregado reemplaza la predictibilidad de todo el sistema—que es también por qué la contabilidad de las secciones siguientes necesita detallarse partida por partida.

Cómo se ve un sistema real en producción

Puedes memorizar definiciones de patrones sin saber cómo se ven en producción. Esta lección tiene una ventaja: Anthropic publicó una retrospectiva de ingeniería sobre su función Research, que es un sistema orquestador-trabajador en ejecución en producción. Esta sección y las siguientes se apoyan en ese balance.

Cita de arquitectura: su sistema Research usa una arquitectura multiagente con un patrón orquestador-trabajador, donde un agente líder coordina el proceso mientras delega a subagentes especializados que operan en paralelo².

Cómo se ve en ejecución: cuando una persona envía una consulta, el agente líder la analiza, desarrolla una estrategia, y lanza subagentes para explorar distintos aspectos simultáneamente².

Fíjate en «la analiza, desarrolla una estrategia»—esa es la decisión en tiempo de ejecución que mencionaba la sección anterior. Alguien pregunta algo; el agente líder averigua en el momento cuántas direcciones perseguir y qué debería investigar cada una.

Vale la pena extraer una cita definicional más: un sistema multiagente consiste en varios agentes (LLM que usan herramientas de forma autónoma en un bucle) trabajando juntos².

Ese paréntesis debería sonarte familiar. Un trabajador no es nada nuevo—es el bucle del arnés que escribiste en el curso 7 de esta serie. Orquestador-trabajadores no introduce una unidad de ejecución nueva; introduce «un bucle que arranca otra tanda de bucles». Ya sabes escribir ese bucle. Esta lección enseña a conectarlos.

La misma retrospectiva explica por qué ayuda el fan-out: la esencia de la búsqueda es la compresión—destilar hallazgos de un corpus enorme. Los subagentes facilitan la compresión al operar en paralelo con sus propias ventanas de contexto, explorando distintos aspectos de la pregunta simultáneamente antes de condensar los tokens más importantes para el agente líder de investigación. Cada subagente aporta además separación de responsabilidades—herramientas, prompts y trayectorias de exploración distintas—lo que reduce la dependencia del camino y habilita investigaciones a fondo e independientes².

«Ventanas de contexto independientes»—esas cuentas ya las sacaste en la Lección 3. Aquí reaparecen en otro papel: no solo capacidad, sino aislamiento. Tres investigaciones no pueden ver los pasos intermedios de las otras, así que no se desviarán del rumbo por los errores ajenos.

El anverso del balance: 90,2 % y ese 80 %

El número más famoso de esta retrospectiva es también el que más se cita mal. Aquí va la cita completa: sus evaluaciones internas muestran que los sistemas multiagente de investigación destacan especialmente en consultas de amplitud primero, que implican perseguir varias direcciones independientes simultáneamente. Encontraron que un sistema multiagente con Claude Opus 4 como agente líder y subagentes Claude Sonnet 4 superó al Claude Opus 4 de agente único en un 90,2 % en su evaluación interna de investigación².

No puedes citar este número sin todas y cada una de estas condiciones:

• En su evaluación interna de investigación—no es un benchmark público, no lo puedes reproducir, y no sabes si se parece a tu distribución de tareas.
• Opus 4 como líder + subagentes Sonnet 4—el resultado de ese emparejamiento concreto. Otra combinación de modelos no promete nada.
• Destaca especialmente en consultas de amplitud primero—las que requieren varias direcciones independientes simultáneamente. Las tareas con dependencias profundas (cada paso espera la conclusión del anterior) quedan fuera del alcance de este enunciado.

Una disciplina crítica más: este número compara multiagente contra agente único, no «orquestación estructurada contra bucles». No lo puedes usar para argumentar que «mover el control de flujo al código le gana a dejar que el modelo corra un bucle»—esa es otra afirmación, y ninguno de los materiales primarios de esta lección los compara. Esta lección usa una y otra vez el eje de «quién sostiene el plan», pero no hay datos primarios de benchmark sobre ese eje, solo compromisos de ingeniería.

¿Por qué es efectivo el multiagente en general? La retrospectiva ofrece una explicación menos romántica—nota que su análisis de respaldo viene de otra evaluación, no de la que produce el 90,2 %: los sistemas multiagente funcionan principalmente porque ayudan a gastar suficientes tokens para resolver el problema. En su análisis de la evaluación BrowseComp (que pone a prueba la capacidad de los agentes de navegación para localizar información difícil de encontrar), tres factores explicaron el 95 % de la varianza de rendimiento, y el uso de tokens por sí solo explica el 80 %, con la cantidad de llamadas a herramientas y la elección del modelo como los otros dos factores explicativos². Dicen que este hallazgo valida su arquitectura, que distribuye el trabajo entre agentes con ventanas de contexto separadas para agregar más capacidad de razonamiento en paralelo².

Las cifras del 95 % y del 80 % solo valen para el análisis de BrowseComp; no las muevas a otra parte como conclusiones generales.

Pero esta explicación del mecanismo tiene un uso práctico: si tu tarea no requiere tantos tokens para resolverse, la base de las ganancias de orquestador-trabajadores desaparece. (Este es un juicio de ingeniería inferido del enunciado del mecanismo, no una consecuencia directa de las cifras del 95 %/80 %.) Una pregunta que se responde con una sola búsqueda en la documentación no se volverá más correcta por despachar tres trabajadores; solo se volverá más cara.

El reverso del balance: 4× y 15×

Estos dos números aparecieron en la Lección 1; aquí va la cita completa. La misma retrospectiva continúa de inmediato: hay una desventaja—en la práctica, estas arquitecturas queman tokens rápido. En sus datos, los agentes suelen usar unas 4× más tokens que las interacciones de chat, y los sistemas multiagente usan unas 15× más tokens que los chats. Para ser viables económicamente, los sistemas multiagente requieren tareas donde el valor de la tarea sea lo bastante alto como para pagar por el aumento de rendimiento².

Pon los números de ambas secciones lado a lado: de un lado, 90,2 % (bajo condiciones específicas); del otro, 15×. La sección anterior dejó claro que la ganancia de rendimiento viene principalmente de gastar tokens, así que la factura más alta no es un efecto secundario—es la otra mitad del mismo mecanismo.

¿Cómo operacionalizas «el valor de la tarea tiene que corresponder»? En realidad te está pidiendo responder una pregunta de negocio antes que una técnica: si esta investigación sale bien, ¿cuánto vale? Si la respuesta es «le ahorra media hora a una persona del equipo», la factura de 15× probablemente no se paga sola. Si la respuesta es «evita un incidente en producción», eso ya es otra historia.

La retrospectiva traza además un límite más duro: algunos dominios que requieren que todos los agentes compartan el mismo contexto, o que implican muchas dependencias entre agentes, hoy no encajan bien con los sistemas multiagente. Por ejemplo, la mayoría de las tareas de programación implican menos tareas verdaderamente paralelizables que la investigación, y los agentes LLM todavía no son buenos coordinándose y delegando a otros agentes en tiempo real². A la inversa, han encontrado que los sistemas multiagente destacan en tareas valiosas que implican paralelización pesada, información que excede una sola ventana de contexto, y trato con numerosas herramientas complejas².

Hay dos frases aquí que deben leerse juntas, o las malentenderás: la fuente oficial del patrón usa la programación como ejemplo de «las subtareas no se pueden predecir»¹, mientras que la retrospectiva multiagente dice que la mayoría de las tareas de programación implican menos tareas verdaderamente paralelizables que la investigación². No se contradicen—hablan de dos cosas distintas. La primera dice que la descomposición debe computarse dinámicamente; la segunda dice que puede que las subtareas computadas no corran todas simultáneamente. La descomposición dinámica no implica paralelismo inevitable. Un orquestador puede perfectamente computar cinco subtareas, y luego ejecutar tres en secuencia y dos en paralelo.

Los cuatro elementos del prompt de delegación

Esta es la disciplina de ingeniería que más deberías recordar de esta lección; la cita original es breve:

"Teach the orchestrator how to delegate. In our system, the lead agent decomposes queries into subtasks and describes them to subagents. Each subagent needs an objective, an output format, guidance on the tools and sources to use, and clear task boundaries. Without detailed task descriptions, agents duplicate work, leave gaps, or fail to find necessary information"².

(Enséñale al orquestador a delegar. En nuestro sistema, el agente líder descompone las consultas en subtareas y se las describe a los subagentes. Cada subagente necesita un objetivo, un formato de salida, guía sobre las herramientas y fuentes a usar, y límites claros de la tarea. Sin descripciones detalladas de la tarea, los agentes duplican trabajo, dejan huecos, o no logran encontrar la información necesaria.)

Cuatro elementos, ninguno opcional:

Objetivo—qué conclusión debe producir este trabajador. No «investiga el rendimiento», sino «encuentra los 3 puntos calientes de CPU en tiempo de ejecución con mayor self-time». El objetivo debe ser lo bastante estrecho como para juzgar si se cumplió.

Formato de salida—cómo se ve el artefacto devuelto. Campos, techo de cantidad de ítems, orden. Este punto determina directamente qué tan fácil es escribir la etapa de síntesis del orquestador: si tres trabajadores devuelven tres párrafos de prosa, la síntesis solo puede apoyarse en que el modelo los vuelva a leer. Si devuelven JSON conforme al mismo esquema, la mitad de la síntesis se puede hacer en código.

Guía sobre herramientas y fuentes—qué herramientas tiene permitido usar, dónde mirar. Este punto es a la vez control de costos y prevención de deriva: si no le das una herramienta de búsqueda web, no puede irse a buscar algo que no existe.

Límites de la tarea—explícitamente qué no debería hacer. Este punto es el más fácil de omitir, y el que más directamente determina si los trabajadores chocan. «No mires dentro de src/server/; ese es territorio de otro trabajador»—una sola frase así es más efectiva que cualquier deduplicación posterior.

El caso de fallo de la retrospectiva es casi de manual: por ejemplo, un subagente exploró la crisis de chips automotrices de 2021 mientras otros 2 duplicaban trabajo investigando las cadenas de suministro actuales de 2025, sin una división del trabajo efectiva².

Tres trabajadores, dos duplicando y uno lanzado hacia un año irrelevante—esto es exactamente cómo se ve «duplican trabajo, dejan huecos» en términos concretos.

Puente con lo que ya aprendiste: el curso 6 de esta serie, al enseñar colaboración multiagente, ya desglosó estos cuatro puntos (llamándolos objetivo, alcance, fuentes y formato de salida); la Lección 2 también los mencionó. Esta lección hace lo que esos dos lugares no hicieron: poner los cuatro elementos en la posición de despachos generados por el orquestador sobre la marcha—ya no controlas el contenido de cada despacho, solo las reglas que el orquestador sigue al generarlos. Los cuatro elementos siguen funcionando como lista de verificación: después de escribir un despacho, cuéntalos uno por uno para confirmar que están los cuatro.

Escalar el esfuerzo según la complejidad: escribir las reglas de asignación en el prompt

Los cuatro elementos resuelven «qué hace cada trabajador»; queda una pregunta: cuántos lanzar, cuánto puede gastar cada uno.

Este conjunto de números apareció en la apertura del curso 6; aquí se usa de otro modo—no para juzgar si usar multiagente, sino para escribirlo en el prompt del orquestador y que él mismo asigne las cuotas. El diagnóstico de la retrospectiva es directo: a los agentes les cuesta juzgar el esfuerzo apropiado para tareas distintas, así que incrustaron reglas de escalado en los prompts. La búsqueda simple de datos requiere apenas 1 agente con 3-10 llamadas a herramientas, las comparaciones directas podrían necesitar 2-4 subagentes con 10-15 llamadas cada uno, y la investigación compleja podría usar más de 10 subagentes con responsabilidades claramente divididas².

Una disciplina de citación sobre estos números: su identidad es «reglas que ellos incrustaron en sus propios prompts», no estándares de la industria, ni escalas que debas copiar al pie de la letra. Tu distribución de tareas, la velocidad de tus herramientas y tus modelos son todos distintos de los suyos. Lo verdaderamente portable es la práctica en sí—escribir las reglas de asignación explícitamente en el prompt del orquestador, en vez de esperar que el orquestador se autorregule.

¿Qué pasa si no las escribes? La retrospectiva aporta la escena: los sistemas multiagente tienen diferencias clave frente a los sistemas de agente único, incluido un crecimiento rápido de la complejidad de coordinación. Los agentes tempranos cometían errores como lanzar 50 subagentes para consultas simples, rastrear la web sin fin buscando fuentes inexistentes, y distraerse entre sí con actualizaciones excesivas².

"Spawning 50 subagents for simple queries" (lanzar 50 subagentes para consultas simples)—convierte eso usando el balance de la sección anterior y lo entenderás: según sus datos, multiagente es unas 15× los tokens de un chat², así que este tipo de fan-out desbocado empuja ese multiplicador mucho más arriba. Las reglas de cuota no son tacañería; son el medio para mantener el costo y el valor de la tarea en el mismo orden de magnitud.

¿Cómo escribes esta regla en el prompt de tu propio orquestador? Sigue su forma y rellena tu propia escala: clasifica tus tareas en unos pocos niveles, especifica para cada nivel el techo de cantidad de subagentes y el techo de llamadas a herramientas por subagente, y luego agrega una cláusula del tipo «si superas el techo, devuelve los hallazgos actuales; no continúes». Esto puede reducir la probabilidad de desbocamiento, pero sigue siendo apenas un prompt—para modelos no deterministas, un techo escrito en el prompt siempre es solo un consejo. La compuerta real está del lado del código: el LIMIT del pool del esqueleto. La capa del prompt se ocupa de la «autoconciencia del modelo»; la capa del código se ocupa del «respaldo». Necesitas las dos.

Cuellos de botella síncronos, y el precio de la asincronía

Esta sección discute problemas que la arquitectura no ha resuelto hoy. El texto original viene en dos párrafos.

Primer párrafo, estado actual: la ejecución síncrona crea cuellos de botella. Actualmente, sus agentes líderes ejecutan a los subagentes de forma síncrona, esperando a que cada tanda de subagentes termine antes de seguir. Esto simplifica la coordinación, pero crea cuellos de botella en el flujo de información entre agentes. Por ejemplo, el agente líder no puede dirigir a los subagentes, los subagentes no se pueden coordinar, y el sistema entero puede quedar bloqueado mientras espera a que un solo subagente termine de buscar².

Tres puntos de «no puede», cada uno correspondiente a una pérdida real:

• El agente líder no puede reorientar sobre la marcha—en el minuto 2 ya puede darse cuenta de que la dirección del trabajador C está equivocada, pero tiene que esperar a que termine la tanda para hacer algo.
• Los subagentes no se pueden coordinar—el trabajador A ya encontró algo, el trabajador B no lo sabe, y podría estar buscándolo de nuevo justo ahora.
• La tanda entera queda bloqueada por el más lento—dos trabajadores que terminan en 3 minutos esperarán junto a uno que agota su tiempo a los 25 minutos, hasta el minuto 25.

Segundo párrafo, el costo del otro camino: la ejecución asíncrona habilitaría paralelismo adicional—agentes trabajando de forma concurrente y creando subagentes nuevos cuando haga falta. Pero esta asincronía agrega desafíos en la coordinación de resultados, la consistencia de estado, y la propagación de errores entre los subagentes².

Fíjate en el tono de esta frase: el material primario enumera estos tres puntos como desafíos, no como problemas resueltos. Así que esta lección no te va a dar «el esquema de orquestación asíncrona recomendado oficialmente»—eso no existe. Si te vas a asíncrono por tu cuenta, estos tres puntos son tuyos para cargar:

• Coordinación de resultados: los trabajadores vuelven a cuentagotas; «cuándo hemos terminado lo suficiente para empezar la síntesis» es un juicio que debes definir tú.
• Consistencia de estado: el agente líder cambió el alcance de la investigación sobre la marcha; los trabajadores en curso siguen usando el alcance viejo; las premisas de ambos lados se bifurcaron.
• Propagación de errores: un trabajador falló, pero su salida intermedia ya se usó para lanzar trabajadores nuevos. Quién de esa cadena debería volver a ejecutarse, de quién se anulan los resultados—esto requiere reglas explícitas.

El ejercicio de Nivel 2 de esta lección te pedirá dar una instancia concreta de cada uno sobre una línea de tiempo específica.

Comportamiento emergente, y la última milla

Algunas lecciones de ingeniería más de la misma retrospectiva; cada una es corta, pero cada una vale un incidente en producción.

Los sistemas multiagente tienen comportamientos emergentes, que surgen sin programación específica. Por ejemplo, cambios pequeños en el agente líder pueden cambiar de forma impredecible cómo se comportan los subagentes. El éxito requiere entender los patrones de interacción, no solo el comportamiento de un agente individual². La misma retrospectiva agrega una línea más dura: en el software tradicional, un bug podría romper una función, degradar el rendimiento, o causar caídas. En los sistemas agénticos, los cambios menores se propagan en cascada hacia cambios grandes de comportamiento, lo que hace notablemente difícil escribir código para agentes complejos que deben mantener estado en un proceso de larga duración².

Impacto en tu trabajo diario: cambia el prompt del orquestador, y debes volver a ejecutar la suite de evaluación entera; no puedes limitarte a revisar la salida del propio orquestador. La pista de evaluación del curso 10 entra en juego aquí—es el único instrumento que tienes para ver si un cambio pequeño sacó de rumbo a los subagentes.

La última milla a menudo se vuelve la mayor parte del viaje: al construir agentes de IA, la última milla a menudo se vuelve la mayor parte del viaje. Los códigos base que funcionan en las máquinas de desarrollo requieren ingeniería significativa para volverse sistemas de producción confiables. La naturaleza compuesta de los errores en los sistemas agénticos significa que problemas menores para el software tradicional pueden descarrilar por completo a los agentes².

Dos prácticas que la acompañan: combinan la adaptabilidad de los agentes de IA construidos sobre Claude con salvaguardas deterministas como lógica de reintento y puntos de control periódicos²; usan despliegues arcoíris para evitar interrumpir a los agentes en curso, desplazando gradualmente el tráfico de las versiones viejas a las nuevas mientras mantienen ambas en ejecución simultáneamente².

Despliegues arcoíris—esto enlaza de vuelta con un problema mencionado en la apertura del curso 9 al usar las actualizaciones de despliegue como escenario de caída: un servicio web normal se reinicia, la gente reintenta una vez y listo. Un agente que lleva 20 minutos en ejecución queda interrumpido por un reinicio, y perdiste 20 minutos de trabajo más los tokens ya gastados. Desplegar tareas de larga duración no es lo mismo que desplegar servicios sin estado.

Calibración: este es el más caro de los cinco patrones

A esta altura ya viste cuatro de los cinco patrones. Ordenados por costo, orquestador-trabajadores es el más caro hasta ahora: sobre la sobrecarga de la paralelización, agrega otra invocación de «que el modelo compute la partición», más el riesgo de «que la partición se compute mal».

Así que antes de empezar, hazte tres preguntas en orden:

Primera, ¿se puede codificar la partición a mano? Si sí, vuelve a la Lección 3 y usa seccionamiento. En seccionamiento, el prompt de cada rama está pulido a mano; en orquestador-trabajadores, los despachos los genera el modelo sobre la marcha—el primero tiene un techo de calidad más alto y es más fácil de depurar. Si lo puedes predefinir, no lo vuelvas dinámico.

Segunda, ¿vale esta tarea tanto dinero? Según sus datos, multiagente es unas 15× los tokens de un chat², y para ser viable económicamente, el valor de la tarea debe ser lo bastante alto como para pagar por el aumento². Este es un juicio de negocio, no técnico, pero hay que hacerlo antes de escribir código.

Tercera, si tienes dudas, mide primero. La postura de cierre de la fuente oficial sobre todo el conjunto de patrones es: estos bloques de construcción no son prescriptivos. La clave del éxito es medir el rendimiento e iterar sobre las implementaciones; habría que considerar añadir complejidad solo cuando mejora demostrablemente los resultados¹. El curso 10 te dio esa pista—primero ejecuta tu conjunto real de tareas con un solo bucle, consigue una línea base, y después juzga si orquestador-trabajadores la levanta. Sin línea base, «se siente mejor» y «gasté 15× para llegar al mismo resultado» se te ven idénticos.

Esta lección solo cubrió «despachar hacia afuera, recolectar de vuelta». Qué pasa si el trabajo devuelto es de baja calidad—si otro agente debería revisarlo, y cómo combinas estos cuatro patrones—ese es el contenido de la Lección 5.

💻 Ejercicios

Resumen

• Orquestador-trabajadores es un flujo de trabajo donde un LLM central descompone dinámicamente las tareas, las delega a LLM trabajadores y sintetiza sus resultados; encaja bien con tareas complejas en las que no puedes predecir las subtareas necesarias¹
• Aunque es topográficamente similar a la paralelización, la diferencia clave es la flexibilidad: las subtareas no vienen predefinidas, sino que las determina el orquestador según la entrada concreta¹—misma forma, distinto momento de la decisión
• Un trabajador no es nada nuevo: un sistema multiagente son varios «LLM que usan herramientas de forma autónoma en un bucle» trabajando juntos, con un agente líder que coordina el proceso y delega a subagentes especializados que operan en paralelo²
• El 90,2 % solo vale en su contexto completo: su evaluación interna de investigación, Claude Opus 4 como líder + subagentes Claude Sonnet 4, destacando especialmente en consultas de amplitud primero²; la explicación del mecanismo es que el multiagente ayuda principalmente a gastar suficientes tokens—en el análisis de BrowseComp, tres factores explican el 95 % de la varianza, y el uso de tokens por sí solo representa el 80 %²
• La factura es la otra cara del mismo balance: según sus datos, los agentes son unas 4× los tokens de un chat, el multiagente unas 15×, y para ser viable económicamente el valor de la tarea debe ser lo bastante alto como para pagarlo²
• Cada subagente necesita un objetivo, un formato de salida, guía sobre las herramientas y fuentes a usar, y límites claros de la tarea; sin descripciones detalladas de la tarea, los agentes duplican trabajo, dejan huecos, o no logran encontrar la información necesaria²—los «prompts de delegación autocontenidos» del curso 6 se expanden en estos cuatro puntos
• A los agentes les cuesta juzgar el esfuerzo apropiado, así que escribe las reglas de asignación en el prompt: su escala es búsqueda simple de datos 1 agente 3-10 llamadas, comparaciones directas 2-4 subagentes 10-15 llamadas cada uno, investigación compleja más de 10 subagentes con división clara²; sin reglas escritas ya vieron las consecuencias—lanzar 50 subagentes para consultas simples, rastrear la web sin fin buscando fuentes inexistentes, distraerse entre sí con actualizaciones excesivas²
• La ejecución síncrona simplifica la coordinación pero bloquea el flujo de información: el agente líder no puede reorientar sobre la marcha, los subagentes no se pueden coordinar, el sistema entero puede quedar bloqueado por un solo subagente²; lo asíncrono habilita más paralelismo, al costo de la coordinación de resultados, la consistencia de estado, y la propagación de errores entre los subagentes—estos tres son desafíos en los materiales primarios, no soluciones resueltas²
• Los sistemas multiagente tienen comportamientos emergentes; cambios pequeños en el agente líder pueden cambiar de forma impredecible el comportamiento de los subagentes; importa entender los patrones de interacción, no solo los agentes individuales²; la última milla a menudo se vuelve la mayor parte del viaje; los códigos base que funcionan en las máquinas de desarrollo requieren ingeniería significativa para volverse sistemas de producción confiables²; las prácticas que la acompañan son salvaguardas deterministas (lógica de reintento, puntos de control periódicos)² y despliegues arcoíris—desplazar el tráfico gradualmente manteniendo ambas versiones en ejecución, evitando interrumpir a los agentes en curso²
• Este es el más caro de los cuatro patrones aprendidos hasta ahora: antes de empezar, confirma que la descomposición verdaderamente no se puede predefinir (si se puede, vuelve al seccionamiento de la Lección 3), y después confirma que el valor de la tarea puede sostener 15×; si tienes dudas, usa la pista del curso 10 para medir primero una línea base—añade complejidad solo cuando mejora demostrablemente los resultados¹

>> Lección 5: El bucle de revisión, y componer patrones en un grafo

Footnotes

1. Building Effective AI Agents — Anthropic Engineering — https://www.anthropic.com/engineering/building-effective-agents ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸

2. How we built our multi-agent research system — Anthropic Engineering — https://www.anthropic.com/engineering/multi-agent-research-system ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵ ↩¹⁶ ↩¹⁷ ↩¹⁸ ↩¹⁹ ↩²⁰ ↩²¹ ↩²² ↩²³ ↩²⁴ ↩²⁵ ↩²⁶ ↩²⁷ ↩²⁸ ↩²⁹ ↩³⁰ ↩³¹ ↩³² ↩³³ ↩³⁴ ↩³⁵ ↩³⁶ ↩³⁷ ↩³⁸