Lección 1: Cuando un solo bucle no basta

Objetivos de aprendizaje:

• Usar una tarea real que rompe a los agentes de un solo bucle para mostrar por qué «conseguir una ventana más grande» no resuelve el problema de forma
• Enunciar la distinción arquitectónica entre flujos de trabajo y agentes, y usar «quién tiene el plan» para ubicar cualquier sistema sobre ese eje
• Enumerar los disparadores para subir de nivel y las condiciones para quedarse donde estás, con la latencia y los costos en tokens sobre la mesa desde el principio

Requisitos: Terminaste los primeros 11 cursos de esta serie y puedes escribir a mano un bucle de arnés impulsado por stop_reason (curso 7, «Fundamentos del arnés de agente: bucles y control») | Siguiente: Lección 2 >>

Para el módulo 30, algo va mal

Necesitas migrar un repositorio de backend del framework interno de RPC v1 al v2. Antes de empezar necesitas un inventario: el repositorio tiene 40 módulos, y cada módulo necesita una evaluación de migración —enumerar los puntos de riesgo, estimar el alcance de los cambios, adjuntar un manifiesto de dependencias—. El trabajo no es difícil, solo es numeroso. Tienes aquel arnés del curso 7 de esta serie:

(Un arnés es el código anfitrión que envuelve las llamadas al modelo: enviar la solicitud, ejecutar las herramientas que el modelo quiere usar, devolver los resultados, decidir si conviene continuar.)

Le entregas la lista de 40 módulos de una sola vez, escribes «evalúa cada uno, un informe por módulo» y te vas a preparar un café.

Los primeros 5 módulos se ven estupendos: hace grep de los sitios de llamada, lee la configuración, revisa los archivos de prueba, y los informes salen más detallados de lo que esperabas.

En el módulo 15 vuelves y revisas los registros. El arreglo messages ya resulta impresionante: la salida de grep de los primeros 14 módulos, trozos enteros de archivos de configuración leídos, acuses de escritura de archivos, rastros de caminos tomados y luego abandonados, todo eso sigue ahí sobre esa misma línea de tiempo. Nada de este contenido era erróneo: cada pieza fue necesaria en su momento. Pero su función actual quedó reducida a una sola cosa: ocupar espacio.

Para el módulo 30, la calidad se desploma. Copia la conclusión del módulo 27 sobre el módulo 30 porque los nombres se parecen; se salta calladamente el paso de «revisar si hay interceptores personalizados» que había hecho siempre antes; para el módulo 34, hasta el formato de salida empieza a derivar.

Tu primera reacción probablemente sea: cambiar a un modelo con una ventana de contexto más grande.

Esa reacción solo te lleva a mitad de camino. Duplica la ventana y el punto de colapso probablemente se mueva del módulo 30 al 55. Tu siguiente repositorio tiene 120 módulos. No resolviste el problema, compraste una prórroga.

Lo que de verdad se agotó no es la ventana, es la forma de «un solo bucle»: 40 elementos independientes forzados a compartir una línea de tiempo, un presupuesto de atención. La calidad de la evaluación del módulo 30 depende de cuánto residuo dejaron atrás los primeros 29 módulos, y esas dos cosas no tienen nada que ver entre sí.

Lo que hace este curso es cambiar esa forma.

Primero, ordenar el vocabulario oficial

Los agentes pueden encargarse de tareas sofisticadas, pero su implementación suele ser sencilla. Son típicamente solo LLM que usan herramientas basándose en la retroalimentación del entorno, dentro de un bucle¹. Aquel while que escribiste en el curso 7 de esta serie es exactamente eso, ni una línea de diferencia. Así que ubícate: ya construiste un agente, este curso no arranca desde cero.

Una capa más arriba. Anthropic clasifica todas estas variaciones como sistemas agénticos (dicho en llano: sistemas armados con modelos, herramientas y alguna forma de flujo de control, capaces de recorrer varios pasos por su cuenta), pero dentro de esta categoría amplia traza una distinción arquitectónica importante¹:

• Los flujos de trabajo son sistemas donde los LLM y las herramientas se orquestan a través de caminos de código predefinidos¹. «Caminos de código predefinidos» es la frase clave: lo que pasa a continuación está escrito en el código.
• Los agentes, en cambio, son sistemas donde los LLM dirigen dinámicamente sus propios procesos y su uso de herramientas, y mantienen el control sobre cómo cumplen las tareas¹. Lo que pasa a continuación lo decide el modelo en el momento.

Un término fundamental más, que usarás una y otra vez en las próximas lecciones. En computación, los sistemas deterministas producen la misma salida cada vez ante entradas idénticas, mientras que los sistemas no deterministas —como los agentes— pueden generar respuestas variadas incluso con las mismas condiciones iniciales².

Aplica esa definición a tu while y verás que son dos cosas cosidas entre sí: cómo enviar la solicitud, cómo ejecutar las llamadas a herramientas, cuándo parar —eso es determinista, lo escribiste tú en código—; mientras que «qué hay que buscar con grep a continuación, si este informe ya está terminado» —eso es no determinista, lo decide el modelo en el momento—. La cirugía que estás a punto de practicar consiste en mover el poder de decisión entre estas dos mitades.

El eje de «quién tiene el plan»

La documentación de Claude Code lo plantea de forma más directa: los subagentes, las Skills, los equipos de agentes y los flujos de trabajo pueden ejecutar todos una tarea de varios pasos. La diferencia está en quién tiene el plan³.

(«Subagente» = un asistente que trabaja de forma independiente en su propia ventana de contexto y devuelve solo un resumen; «fan-out» = despachar varios subagentes para que trabajen a la vez. El curso 6 de esta serie cubrió ambos términos.)

Esa oración atraviesa un montón de enfoques que se parecen entre sí. Toma «ejecutar evaluaciones para 40 módulos»:

• Dejas que el modelo recorra los 40 en una sola conversación: el plan está en manos del modelo, y es implícito, escondido en el historial de la conversación. Tendrías que escarbar en los registros para adivinar el camino que pretendía seguir.
• Conviertes al modelo en orquestador, y decide en cada turno qué subagente despachar para qué módulo: el plan sigue en manos del modelo, solo que un poco más explícito.
• Escribes un script, y el script recorre esos 40 módulos con un for: el plan está en el código. Puedes abrir el archivo y leerlo entero, y ejecutarlo mañana otra vez sin cambios.

El tercer enfoque tiene una descripción precisa: un flujo de trabajo mueve el plan al código. El script del flujo de trabajo retiene él mismo el bucle, las bifurcaciones y los resultados intermedios, de modo que el contexto de Claude retiene solo la respuesta final³. Y los resultados intermedios se quedan en variables del script en lugar de aterrizar en el contexto de Claude³. La salida de grep del módulo 27 se queda en un arreglo de JavaScript, así que la evaluación del módulo 30 naturalmente no puede verla: no porque el modelo haya aprendido a ignorarla, sino porque nunca tuvo la oportunidad de verla.

Para los dos extremos de este eje, la guía oficial le dedica a cada uno una oración sobre su encaje: cuando se justifica más complejidad, los flujos de trabajo ofrecen previsibilidad y consistencia para tareas bien definidas, mientras que los agentes son la mejor opción cuando hacen falta flexibilidad y toma de decisiones dirigida por el modelo a escala¹.

Una aclaración: este curso llama a este eje el «espectro de determinismo» y llama a los patrones de composición de la lección 5 «grafos», «nodos» y «aristas». Esas etiquetas son metáforas de ingeniería propias de este curso y nunca aparecen en las fuentes primarias: los materiales primarios solo aportan las definiciones de los dos extremos (caminos de código predefinidos frente a decisiones dirigidas por el modelo)¹ y el planteamiento de «quién tiene el plan»³. Tomamos prestadas las metáforas del espectro y del grafo porque resultan cómodas para ordenar patrones que sí existen de verdad; no vas a leer estos términos en ninguna documentación oficial, así que no los presentes como conceptos oficiales.

Cuándo subir de nivel

«Un solo bucle no basta» suena a intuición, pero hay disparadores que sí se pueden enunciar.

Disparador uno: la tarea necesita más agentes de los que una sola conversación puede coordinar, o quieres la orquestación codificada como un script que puedas leer y volver a ejecutar³. La primera mitad es un asunto de capacidad, la segunda es un asunto de ingeniería: aunque una sola conversación apenas logre coordinarlo, «¿podemos ejecutar esto exactamente igual mañana?» califica como razón por sí sola.

Disparador dos: cuando la tarea es más grande de lo que un solo agente puede retener en contexto, o cuando el mismo paso necesita ejecutarse a lo largo de muchos elementos³. Estas dos oraciones juntas describen exactamente el escenario de los 40 módulos del principio. Fíjate en la segunda: la cantidad de elementos es una razón por sí misma, sin importar si cada elemento es difícil.

Disparador tres: cuando una tarea lateral inundaría tu conversación principal. La descripción del escenario en la documentación de subagentes: cuando una tarea lateral inundaría tu conversación principal con resultados de búsqueda, registros o contenidos de archivos que no volverás a consultar, despacha un subagente, que hace ese trabajo en su propio contexto y devuelve solo el resumen⁴, preservando el contexto al mantener la exploración y la implementación fuera de tu conversación principal⁴. Nota que este disparador receta «despachar un subagente»: el plan sigue quedándose en manos del modelo; eso y «mover el plan al código» son dos cosas distintas. Las columnas B y C del ejercicio de Nivel 2 desglosarán esta distinción.

Mira este código para hacerte una idea de qué forma queda después del cambio:

El bucle sigue siendo aquel bucle: dentro de runHarnessLoop está el while que escribiste en el curso 7 de esta serie. Solo cambió una cosa: quién cuenta hasta 40. Antes contaba el modelo. Ahora cuenta el for.

Cuándo quedarse donde estás

Detrás de las señales de disparo hay una lista de comprobación igual de larga en sentido contrario, y esta es más fácil de saltarse.

Encuentra la solución más simple posible, y aumenta la complejidad solo cuando haga falta. Esto podría significar no construir sistemas agénticos en absoluto¹. Para muchas aplicaciones, sin embargo, optimizar llamadas individuales al LLM con recuperación y ejemplos en contexto suele bastar¹. Ese trabajo de renombrar una función en 12 lugares no necesita un arnés, no necesita orquestación: una llamada más un grep y está listo.

Algunos dominios hoy no encajan bien con los sistemas multiagente: los que requieren que todos los agentes compartan el mismo contexto, o donde hay muchas dependencias entre agentes. El texto nombra un 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 muy buenos coordinándose con otros agentes y delegándoles en tiempo real⁵. Estás refactorizando un módulo de pedidos fuertemente acoplado, y los cambios se propagan por una cadena de llamadores; repartir esto en abanico a cinco subagentes solo lo hace más lento y más enredado, porque todos necesitan mirar lo mismo, y quien se mueva primero invalida la información de todos los demás.

A la inversa, las condiciones de encaje positivo están enunciadas con la misma llaneza: encontraron que los sistemas multiagente destacan en tareas que implican mucha paralelización, información que excede una sola ventana de contexto, e interactuar con numerosas herramientas complejas⁵, y tareas donde el valor de la tarea es lo bastante alto como para pagar por el rendimiento añadido⁵. Cuantas más de estas tres condiciones cumplas, más vale la pena subir de nivel.

Hay además una categoría de tareas que habría que dejar en bucles autónomos, sin forzarlas hacia la orquestación: problemas abiertos donde es difícil o imposible predecir la cantidad de pasos necesaria, y donde no puedes fijar en duro un camino fijo; estos se les pueden dar a los agentes, que potencialmente operarán durante muchos turnos, y tienes que tener cierto nivel de confianza en su toma de decisiones¹. El propio sistema de investigación de Anthropic es de este tipo: el trabajo de investigación implica problemas abiertos donde es muy difícil predecir de antemano los pasos necesarios. No puedes fijar en duro un camino fijo para explorar temas complejos, porque el proceso es inherentemente dinámico y dependiente del camino⁵.

Así que «¿debería pasarme a la orquestación?» no es una barra de progreso de un solo sentido. La evaluación de los 40 módulos debería moverse hacia la orquestación porque los pasos son fijos, solo que numerosos; «¿deberíamos cambiar la cola de mensajes de A a B?» no debería moverse hacia la orquestación porque ni siquiera sabes cuántos artículos vas a necesitar leer.

Poner los costos sobre la mesa primero

Antes de empezar a aprender los cinco patrones, abre el libro de cuentas.

Los sistemas agénticos a menudo intercambian latencia y costo por un mejor desempeño en la tarea, y habría que considerar cuándo tiene sentido ese intercambio¹. Ni una palabra de aquí es retórica: está describiendo un intercambio.

¿Qué tan caro? Anthropic aporta un conjunto de observaciones de sus propios 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⁵. Así que su conclusión es: para ser económicamente viables, los sistemas multiagente requieren tareas donde el valor de la tarea sea lo bastante alto como para pagar por el rendimiento añadido⁵.

Fíjate en el contexto de este número: viene de sus propios datos, no de un banco de pruebas universal, y no dice «todos los enfoques de orquestación cuestan 15× más». Pero la dirección es clara: cada paso que das hacia «más agentes, más paralelismo», la cuenta salta un escalón. Un límite rápido: este multiplicador mide sistemas multiagente respecto al chat, no la etiqueta de precio de «mover el plan al código» en sí; los materiales primarios nunca dieron una cifra de costo independiente para los scripts de orquestación. Esto es también por lo que a esos 40 módulos les vale la pena subir de nivel y a los 12 renombres no: no porque uno sea «complejo» y el otro «simple», sino porque una evaluación de migración que ahorra dos semanas de retrabajo puede permitirse este costo.

Las cinco lecciones que siguen

El resto de este curso empieza con la forma más ligera y avanza hacia la composición:

• Lección 2: Encadenamiento y enrutamiento: Partir una tarea en pasos fijos con compuertas programáticas entre cada uno; clasificar y luego despachar hacia prompts especializados. La forma más ligera de «el plan en el código».
• Lección 3: Paralelización: Seccionamiento (partir en subtareas independientes ejecutadas en paralelo) y votación (ejecutar la misma tarea varias veces para obtener salidas diversas), además de cómo agregar resultados en código.
• Lección 4: Orquestador-trabajadores: Un LLM central descompone tareas dinámicamente, delega en LLM trabajadores y sintetiza sus resultados. La diferencia clave: las subtareas no están predefinidas.
• Lección 5: Bucles de evaluación y composición de patrones en grafos: Revisar, corregir y volver a revisar hasta que pase o deje de haber progreso, y luego coser los patrones anteriores. Esa lección volverá a enunciarlo: «grafo» es una visualización propia de este curso.
• Lección 6: Manos a la obra: Convertir aquel arnés de un solo bucle del curso 7 de esta serie en un script de orquestación determinista.

Esta taxonomía de patrones no es una reliquia de 2024: la documentación actual de orquestación multiagente de la plataforma Claude sigue nombrando de forma independiente Parallelization (repartir subtareas independientes en abanico a la vez, y que el coordinador sintetice los resultados), Specialization (enrutar hacia agentes con prompts de sistema y herramientas centrados en un dominio), Escalation (consultar a un agente o modelo más capaz para un subconjunto de subtareas complejas)⁶. Cambió la piel, el esqueleto es el mismo.

Una cosa más sobre cómo se separa este curso de los dos anteriores: el curso 2 de esta serie enseñó el concepto de flujo de trabajo —pasos, estado, bifurcaciones, entendimiento a nivel de diagrama—; el curso 6 de esta serie enseñó la división del trabajo y la comunicación en la colaboración multiagente —fan-out, prompts de delegación autocontenidos, productor-revisor—. Este curso no vuelve a enseñar ninguno de los dos. Lo que cubre es el flujo de control en sí: quién cuenta, quién bifurca, adónde van los resultados intermedios, qué pasa cuando se cae. Un puente rápido de vocabulario: a lo que el curso 6 de esta serie llamó «productor-revisor», los materiales primarios lo llaman evaluator-optimizer¹, y la documentación de flujos de trabajo de Claude Code lo llama hacer que agentes independientes revisen de forma adversarial los hallazgos de los demás³.

Proporcionalidad: todo tiene que pasar por «mejora medible»

Este curso te enseñará cinco patrones y un montón de métodos de composición. Todos comparten la misma línea de reconocimiento, y el texto original es inequívoco: estos bloques de construcción no son prescriptivos. Son patrones comunes que los desarrolladores pueden moldear y combinar para encajar con distintos casos de uso. La clave del éxito, como con cualquier funcionalidad de LLM, es medir el desempeño e iterar sobre las implementaciones. Lo repetimos: habría que considerar añadir complejidad solo cuando mejora demostrablemente los resultados¹.

«Mejora demostrablemente los resultados» requiere respaldo concreto, y ese respaldo viene de las evaluaciones del curso 10 y de la observabilidad del curso 11 de esta serie: sin un conjunto de evaluación, no puedes decir con claridad «¿añadir enrutamiento mejoró de verdad las cosas?». El cierre del texto canónico sigue este orden: empieza con prompts simples, optimízalos con una evaluación exhaustiva, y añade sistemas agénticos de varios pasos solo cuando las soluciones más simples se queden cortas¹.

Así que después de aprender cada patrón, pregúntate: ¿puedo producir un número que muestre que los resultados mejoraron después de añadirlo? Si no puedes, todavía no lo añadas.

💻 Ejercicios

Resumen

• Aquel while que escribiste en el curso 7 de esta serie es un agente: los agentes pueden encargarse de tareas sofisticadas, pero su implementación suele ser sencilla, y son típicamente solo LLM que usan herramientas basándose en la retroalimentación del entorno, dentro de un bucle¹.
• Estas variaciones se llaman en conjunto sistemas agénticos, y dentro de ellas se traza una distinción arquitectónica: los flujos de trabajo son sistemas donde los LLM y las herramientas se orquestan a través de caminos de código predefinidos, y los agentes son sistemas donde los LLM dirigen dinámicamente sus propios procesos y su uso de herramientas, manteniendo el control sobre cómo cumplen las tareas¹.
• El eje que los distingue es «quién tiene el plan»: un flujo de trabajo mueve el plan al código, el script mismo retiene el bucle, las bifurcaciones y los resultados intermedios, de modo que el contexto de Claude retiene solo la respuesta final³. Este curso llama a este eje el «espectro de determinismo» y llama a la visualización de composición de la lección 5 «grafos»; ambos términos son metáforas propias de este curso y no aparecen en los materiales primarios.
• Disparadores para subir de nivel: la tarea necesita más agentes de los que una sola conversación puede coordinar, o quieres la orquestación codificada como un script que puedas leer y volver a ejecutar³; cuando la tarea es más grande de lo que un solo agente puede retener en contexto, o cuando el mismo paso necesita ejecutarse a lo largo de muchos elementos³; cuando una tarea lateral inundaría tu conversación principal con contenido que no volverás a consultar⁴.
• Condiciones para quedarse donde estás: encuentra la solución más simple posible y añade complejidad solo cuando haga falta, lo que podría significar no construir sistemas agénticos en absoluto¹; para muchas aplicaciones, optimizar llamadas individuales al LLM con recuperación y ejemplos en contexto suele bastar¹; los dominios que requieren contexto compartido o muchas dependencias entre agentes hoy no encajan bien con multiagente, y la mayoría de las tareas de programación implican menos tareas verdaderamente paralelizables que la investigación⁵.
• Dejar en bucles autónomos: problemas abiertos, difíciles de predecir en cuanto a la cantidad de pasos, sin poder fijar en duro un camino fijo¹; el trabajo de tipo investigación es el caso típico, porque el proceso es inherentemente dinámico y dependiente del camino⁵.
• Consigue la cuenta primero: los sistemas agénticos a menudo intercambian latencia y costo por un mejor desempeño en la tarea¹; en sus propios datos, los agentes usan unas 4× más tokens que el chat, los multiagente unas 15×, y la viabilidad económica requiere que el valor de la tarea sostenga esa mejora⁵.
• Todo lo que enseña este curso tiene que pasar por la misma compuerta: añade complejidad solo cuando mejora demostrablemente los resultados¹; empieza con prompts simples, optimízalos con una evaluación exhaustiva, y añade sistemas agénticos de varios pasos solo cuando las soluciones más simples se queden cortas¹.

>> Lección 2: Encadenar y enrutar: encadenamiento y enrutamiento