Clase 3 · 18 min
Hay cinco formas comunes de poner a un agente en loop, y responden de manera distinta a dos preguntas: qué dispara el siguiente turno y quién decide parar. Elegir mal sale caro: un /loop esperando una condición que nunca llega, un /goal que cree lo que el agente dijo. Aquí queda solo lo que la documentación oficial confirma, leída el 19/10/2026.
Empezar la lección
Objetivo: elegir el motor de loop correcto para una tarea sabiendo dónde corre, qué dispara el siguiente turno, quién decide parar y el límite de cada uno.
Haz clic en cada motor: qué dispara el siguiente turno, quién decide parar y el límite que da la doc oficial.
Desplázate por la página: cada etapa de abajo ilumina su parte del diagrama.
Después de cada turno, un modelo pequeño juzga tu condición: cumplida, no cumplida o imposible. Es un Stop hook basado en prompt, por sesión. Límite: el evaluador no ejecuta comandos ni lee archivos, solo juzga la conversación; la prueba tiene que estar impresa. No cambia el modo de permisos. Con -p corre hasta el final en una sola llamada.
Repite un prompt en un intervalo fijo (/loop 5m …) o elegido por Claude en cada vuelta, de 1 minuto a 1 hora. Límites: es de la sesión y solo se dispara con Claude Code abierto y ocioso; mínimo de 1 minuto; la tarea recurrente expira en 7 días; el auto-ritmado no vuelve con --resume. Sirve para vigilar, no para perseguir una condición.
Técnica descrita por Geoffrey Huntley: en su forma pura, un ciclo de bash que llama al agente con el mismo prompt, sin fin. Cada sesión es descartable; lo que queda está en los archivos y en git. Anthropic cita el patrón como convergencia de la comunidad. Límite: no trae parada ni verificación de fábrica; las pones tú (lecciones 6 y 7).
Configuración guardada (prompt, repositorios, conectores) que corre en la infraestructura de Anthropic, con la laptop cerrada. Límites: está en research preview (el comportamiento y los límites pueden cambiar); trabaja en un clon nuevo, sin acceso a tus archivos locales; intervalo mínimo de 1 hora en la agenda.
Corre Codex sin interfaz: recibe el pedido por argumento o stdin, trabaja y sale. Por defecto la sandbox es de solo lectura; --sandbox workspace-write habilita la edición. --json entrega los eventos en JSONL, -o guarda el último mensaje, exec resume --last continúa la anterior. Límite: no es un loop; el ciclo, la prueba y la parada quedan en un script tuyo (el loop headless es el curso 2).
¿El siguiente turno viene de una condición, de un reloj o de un ciclo tuyo? ¿Y quién decide parar: un evaluador que lee la conversación, tú, o una prueba que corre de verdad? El motor que corre la prueba fuera de la conversación es el más difícil de engañar.
Fuentes: docs oficiales de Claude Code (/goal, scheduled tasks, routines) y de Codex (modo no interactivo), leídas el 19/10/2026; ghuntley.com/ralph.
Una regla de bolsillo a partir de los límites de arriba.
Migrar un módulo hasta que compile y pasen las pruebas, vaciar una cola de issues. La condición necesita un estado final, el comando que lo prueba y lo que no puede cambiar en el camino.
Pon un tope en la propia condición, como sugiere la doc: "o detente después de 20 turnos".
python3 -m pytest -q tests/ imprime 6 passed, ningún archivo en tests/ fue modificado, o detente después de 15 turnos
¿Terminó el deploy? ¿Pasó el CI? ¿Llegó un comentario en el PR? El tiempo dispara la vuelta y cada vuelta mira de nuevo.
Cierra el terminal y se detiene. Para durar más que la sesión, usa agenda en la nube, en el Desktop o GitHub Actions, como indica la propia doc.
Cada ciclo es una sesión nueva que relee el estado en un archivo; quien decide continuar es la prueba ejecutada por el script, no la conversación.
Es lo que hace el kit execucao-longa con tope de tiempo y de memoria (curso 2).
Revisión de PR por evento, triaje nocturno de issues: trabajo repetible en un repositorio, sin depender de los archivos de tu máquina.
Como está en research preview, revisa los límites en la doc antes de depender de él.
Comandos de la documentación oficial y del artículo de Ralph. Ejecuta solo los que vayas a usar en la práctica.
/goal python3 -m pytest -q tests/ imprime 6 passed y git diff --stat -- tests/ sale vacío, o detente después de 15 turnos /goal clear claude -p "/goal CHANGELOG.md tiene una entrada para cada PR de esta semana" --output-format stream-json --verbose
/loop 5m revisa si el deploy terminó y dime qué pasó /loop revisa si el CI pasó y responde a los comentarios de revisión
while :; do cat PROMPT.md | claude-code ; done
codex exec "cuenta los archivos .md de esta carpeta y responde solo con el número" codex exec --sandbox workspace-write "crea ola.txt con la palabra ola" codex exec --json "resume la estructura del repositorio" > eventos.jsonl codex exec resume --last "ahora corrige lo que encontraste"
Tal como está, el loop no tiene parada ni verificación: corre hasta que presiones Ctrl+C. El nombre del ejecutable en el artículo es el del autor; en tu máquina sería claude -p o codex exec -. En las clases 6 y 7 agregas el criterio y los topes que faltan.
El kit execucao-longa usa /goal también en Codex (con /goals y /goal pause|resume). La investigación de esta formación no encontró la página oficial con fecha y límites; por eso este curso no afirma nada más allá del uso en el kit.
En tu máquina. Son ejecuciones cortas: gastan poco de tu cuota.
En una carpeta vacía con git iniciado, abre Claude Code y ejecuta: /goal el archivo ola.txt existe y cat ola.txt imprime ola en la conversación, o detente después de 5 turnos.
Listo cuando: cat ola.txt → ola, y el estado del goal en Claude Code muestra la condición como alcanzada, con el conteo de turnos.
En la misma carpeta, pídele a Codex sin interfaz que cuente archivos, guardando el último mensaje en un archivo.
Listo cuando: codex exec -o resposta.txt "¿cuántos archivos .txt hay en esta carpeta? responde solo con el número"; echo "saída: $?" → saída: 0, y grep -cE '^[0-9]+$' resposta.txt → 1 (la respuesta es una sola línea con un número; el criterio comprueba el formato, no lo que respondió el modelo).
Lista tres tareas reales tuyas en un archivo motores.md, una por línea, en el formato tarea → motor → por qué (disparador y quién decide parar).
Listo cuando: grep -c '→.*→' motores.md → 3, y ninguna tarea con fin verificable quedó con /loop.
Pregunta 1 de 5
Tu condición del /goal es "todos los tests pasan". El agente escribe "ejecuté los tests, todos pasan" sin mostrar la salida. ¿Qué pasa?competencia
Pregunta 2 de 5
Quieres revisar el CI cada 10 minutos durante la tarde, con el terminal abierto. ¿Qué motor?
Pregunta 3 de 5
¿Por qué una routine no sirve para correr las pruebas de un proyecto que solo existe en tu notebook?
Pregunta 4 de 5
¿Qué le falta al Ralph en su forma pura, while :; do cat PROMPT.md | claude-code ; done?competencia
Pregunta 5 de 5
¿Un /loop recurrente creado hoy seguirá corriendo dentro de un mes?
Elige una alternativa. La explicación aparece después de tu intento.