🔄 El ciclo real de ejecución

¿Eres nuevo aquí? O ciclo de ejecución es la secuencia que el agente repite varias veces durante una sesión: leer el paso del workflow, elegir una herramienta, ejecutarla, revisar el resultado y decidir qué hacer después. No es un paso único: es un loop (bucle, repetición: la misma secuencia se ejecuta una y otra vez) que continúa hasta que la tarea esté completa.

En el módulo 1.1 viste la analogía de la cocina: la receta (workflow), el cocinero (agente), los utensilios (tools). Allí quedó quieta, como una foto del plato terminado. Este módulo es la película: el cocinero lee el siguiente paso, toma el cuchillo adecuado, corta, prueba el resultado y solo entonces pasa la página. Es ese «leer → decidir → actuar → probar → repetir» lo que convierte una receta estática en trabajo de verdad: un informe listo, un boletín enviado, un lote de facturas organizado.

Cada vuelta completa del loop se llama iteración. Una tarea sencilla lleva 3 o 4; organizar un mes de facturas puede llevar decenas: el agente decide en cada vuelta si ya terminó.

Leyenda: esta línea de tiempo es UNA iteración del loop: una vuelta completa. El paso 5 apunta de vuelta al paso 1 (no dibujado aquí) porque el ciclo se reinicia hasta que termina el workflow.

Cada vez que el ciclo vuelve a empezar, el agente necesita saber «en qué punto de la receta estoy». En una sesión de Claude Code esto normalmente ocurre dentro de una sola conversación: el historial de la conversación cumple la función de memoria a corto plazo y recuerda lo que ya se hizo. En cambio, en un workflow guardado en un archivo (lo que vamos a practicar en el módulo 1.5), el paso actual puede quedar explícito en el propio texto o inferirse de lo que ya existe en el disco; por ejemplo, si el archivo «relatorio-semana.md» ya existe, el paso 4 ya se cumplió.

¿Eres nuevo aquí? Contexto es todo lo que el agente «ve» al tomar una decisión: la conversación hasta ese momento, los archivos que ya leyó, CLAUDE.md y el resultado de las herramientas que ya ejecutó. Piensa en el contexto como la mesa de trabajo del cocinero: solo usa lo que tiene sobre ella en ese momento; un ingrediente en un armario cerrado (un archivo que nunca abrió) simplemente no existe para él. Ese contexto tiene un costo, medido en tokens — fragmentos de texto que el modelo procesa en cada turno. Cuantas más cosas haya "sobre la mesa", más tokens se gastan solo en revisar todo antes de decidir.

Ejemplo: en un workflow para "responder correos de clientes", en cada iteración el agente lee el siguiente correo (el "dónde estoy"), decide si responde con una plantilla o escala el caso a una persona, ejecuta y observa si el envío se realizó correctamente. El "estado" es solo cuántos correos ya se procesaron.

Esta es la parte más «inteligente» del ciclo: dado el paso actual y la lista de herramientas disponibles, el agente elige la que mejor resuelve esa tarea. Si el paso es «sumar por categoría», puede elegir ejecutar un script de cálculo en vez de intentar sumar manualmente. Si el paso es «publicar en el sitio», elige la herramienta de deploy (tema de la Trilha 4), no una de correo electrónico.

Esta elección depende directamente de qué herramientas se pusieron a disposición del agente — por eso las Trilhas 2 (MCP) y 3 (Skills) de este curso enseñan a conectar herramientas: cuanto más claro sea el menú de opciones, mejor será la elección.

Otro ejemplo: en un «informe semanal de ventas», el paso «sumar la facturación por vendedor» tiene dos herramientas candidatas: un script que suma o fórmulas manuales. Un agente bien configurado elige el script, más rápido y determinista, si está disponible. Si no, se las arregla, lo que nos lleva al error más común.

Después de ejecutar, el agente no sigue a ciegas con el siguiente paso: lee lo que devolvió la herramienta. Un comando puede devolver un error, un archivo vacío, un número fuera de lo esperado o exactamente lo que debería. Leer ese resultado activa la autocorrección, que se explica en profundidad en el módulo 1.3.

Leyenda: el loop avanza de izquierda a derecha en cada paso del workflow; la flecha punteada de regreso muestra la autocorrección: el agente repite un paso que no salió como esperaba.

"Observar" no es opcional ni automático: es una decisión activa de detenerse y leer el resultado antes de continuar. En el ejemplo del boletín informativo (módulo 1.5), después de "enviar correo electrónico", el agente comprueba si apareció "éxito" o un código de error. Con las facturas, después de mover un archivo comprueba si realmente está en la carpeta; no da por hecho que salió bien solo porque el comando "se ejecutó sin trabarse".

Esta lectura tiene tres resultados: (1) coincide con lo esperado, sigue adelante; (2) aparece un error claro, el agente intenta corregirlo o te avisa; o (3) el resultado es ambiguo — ni correcto ni claramente incorrecto — y ahí es donde entra el análisis profundo del módulo 1.3 sobre autocorrección.

1. Leia a pasta atual e liste os arquivos .txt que existem.
2. Para cada arquivo .txt encontrado, conte quantas linhas ele tem.
3. Crie um arquivo resumo.md com o nome de cada arquivo e sua contagem de linhas.
4. Confira se resumo.md foi criado e se o número de linhas listadas bate com os arquivos originais.

El ciclo se repite paso a paso hasta que termina el workflow. En cada vuelta, el agente también decide si necesita repetir el paso actual (por ejemplo, si un comando falló por un motivo temporal) o si debe detenerse y pedirte ayuda (por ejemplo, si falta una contraseña que solo tú tienes). Este segundo caso —detenerse y avisar— es tan importante como ejecutar: un buen agente sabe reconocer cuándo no debe seguir por su cuenta.

¿Eres nuevo aquí? Este momento de decisión — evaluar si seguir, repetir o detenerse según el resultado observado — es lo que llamamos razonamiento del agente. Sin él, el ciclo sería solo una secuencia ciega de comandos, incapaz de reaccionar ante imprevistos.

En el ejemplo de los correos electrónicos: un ciclo saludable vuelve a intentar «enviar» solo si la falla es temporal y se detiene después de 2-3 intentos para escalar el caso contigo. Un ciclo atascado insiste con el mismo error decenas de veces sin obtener un resultado nuevo.

El ciclo termina de tres maneras: (1) el workflow llegó al último paso y todo salió bien: éxito; (2) el agente identificó que falta algo que solo tú puedes proporcionar y se detuvo para preguntar; o (3) se quedó atascado repitiendo y es hora de que intervengas. Reconocer cuál de las tres está ocurriendo es el tema central del módulo 1.4.

Vale la pena reforzar la diferencia entre los finales 2 y 3 — parecidos a primera vista, ambos terminan sin el resultado listo. En el final 2 (pausa por decisión), el agente sabe qué falta y hace una pregunta específica, como "necesito la clave de la API de Gmail — ¿dónde la encuentro?". En el final 3 (bloqueo), ya no sabe qué más intentar y repite algo que ya demostró no funcionar — entonces la solución es que ajustes el workflow, no responder.

En el ejemplo de las facturas: hay éxito cuando todas están en las carpetas correctas y hay un resumen por categoría; hay una pausa por decisión cuando el agente encuentra una factura sin una categoría clara y pregunta dónde clasificarla; hay un bloqueo cuando intenta abrir repetidamente un PDF dañado sin conseguirlo: es hora de que revises el archivo manualmente.