Ingeniería de loops: diseñando agentes que iteran, verifican y recuerdan
La respuesta breve
La mayoría de los flujos de trabajo con Claude empiezan como prompting manual: prompt, esperar, inspeccionar, decidir qué pedir después. Eso funciona para tareas puntuales, pero falla cuando el trabajo es repetitivo, con estado o requiere varias rondas de verificación. En ese caso, la abstracción útil no es un mejor prompt — es un loop.
Un loop de Claude es un flujo de trabajo repetible alrededor del modelo. Define qué desencadena la ejecución, qué contexto lee Claude, qué se le permite hacer, cómo se verifica la salida, dónde se almacena el estado y cuándo el loop se detiene, se repite o escala a un humano.
Un loop tiene seis partes:
- Disparador — comando manual, programación, cambio de archivo, evento de Git, CI fallido.
- Contexto — la tarea, archivos relevantes, instrucciones, progreso previo.
- Acción — Claude realiza el siguiente paso.
- Verificación — el resultado se comprueba frente a una condición concreta.
- Actualización de estado — qué pasó, qué cambió, qué debe pasar después.
- Decisión — detenerse, pedir revisión humana o ejecutar otra iteración.
Cuándo construir un loop (y cuándo no)
Un loop añade estructura, persistencia y automatización — pero también coste y complejidad. Vale la pena cuando la tarea es repetitiva, con estado y verificable:
- Repetitiva — ocurre con la suficiente frecuencia como para justificar la configuración.
- Con estado — cada ejecución se beneficia de recordar ejecuciones previas.
- Verificable — existe una forma concreta de rechazar una salida mala.
Haz una comprobación de preparación para el loop antes de comprometerte: ¿se repite? ¿se puede verificar el resultado? ¿tiene Claude contexto? ¿hay una condición clara de parada? ¿hay un punto seguro de revisión?
Un mal primer loop: "Cada día, mejorar el documento de estrategia de producto hasta que se sienta mejor." Vago, sin condición de parada, sin verificación. Un buen ejemplo: "Cada viernes, revisar el documento de estrategia, listar qué cambió, escribir una nota estructurada en outputs/strategy-review.md. No editar el documento directamente."
La escalera de permisos — la mayoría de los primeros loops deberían comenzar en Nivel 1 o 2:
- Análisis de solo lectura
- Borrador de salida (informes en una carpeta
outputs/) - Ediciones en sandbox
- Borrador de acción externa (PR/mensaje/ticket de borrador)
- Acción con aprobación humana
- Acción totalmente automatizada de bajo riesgo
El loop mínimo viable
Un loop mínimo necesita: una tarea, un archivo de contexto, un archivo de estado, una ubicación de salida y un paso de verificación.
minimal-claude-loop/
├── TASK.md # el objetivo del loop
├── PROGRESS.md # estado entre ejecuciones
├── LOOP_INSTRUCTIONS.md # cómo comportarse en cada iteración
└── outputs/
└── daily-review.md # donde aterrizan los resultados
El primer loop debe ser aburrido por diseño: leer contexto, hacer un trabajo restringido, escribir en un lugar predecible, actualizar el estado, detenerse. La repetibilidad vence a la autonomía.
Estado persistente: PROGRESS.md
Lo que convierte a una repetición en un loop no es el re-prompt, sino el estado fuera de la sesión. Esta es la diferencia más importante entre prompting y la ingeniería de loops: en el prompting manual, la continuidad vive en la conversación; en un loop, debería vivir en el workspace.
PROGRESS.md es la interfaz de memoria del loop. Léelo antes de actuar, actualízalo antes de detenerte. Si falta, está desactualizado o es demasiado largo, el loop pierde continuidad.
Mantenlo corto y estructurado: estado actual, última ejecución, elementos abiertos, bloqueadores, needs-human-review, siguiente ejecución debe, decisiones tomadas, do-not-repeat. "Si Claude lo necesita para decidir la siguiente acción, guárdalo en PROGRESS.md. Si un humano puede querer inspeccionarlo después, almacénalo en outputs/."
El archivo de estado también es una superficie de control y un mecanismo de seguridad — las secciones Do Not Repeat y Needs Human Review evitan que el loop reintente acciones fallidas o continúe silenciosamente tras una decisión que requiere juicio.
Verificación: separar al trabajador del verificador
Un loop no debería detenerse porque Claude dice que ha terminado. Debe detenerse porque se ha comprobado una condición concreta: existe un archivo, está presente una estructura, pasa una prueba, se completa una lista de verificación.
Usa el patrón maker-checker: un trabajador produce, un verificador evalúa según criterios explícitos. Incluso en una sola ejecución de Claude, escríbelos como fases separadas. El sistema que genera la salida no debería ser la única señal que la aprueba.
Un verificador débil es otro optimista: "Revisa la salida y dime si parece bien." Un verificador sólido tiene un estándar:
> "Para cada ítem, devuelve PASS o FAIL. No asumas que una sección faltante está presente. No marques como completo si algún elemento requerido falla."
Define qué ocurre en caso de fallo: reintentar (pequeño, seguro), escalar (requiere juicio / es arriesgado), o detener (límite de iteraciones/permiso/presupuesto alcanzado). Añade un límite de iteraciones para que no entre en bucle infinito.
Programación con /loop
Una vez que el loop funciona de forma fiable manualmente, prográmalo. /loop es la forma más rápida de volver a ejecutar un prompt en un intervalo mientras la sesión permanece abierta.
/loop 24h Run the daily project review loop for this workspace.
Follow LOOP_INSTRUCTIONS.md exactly. Read TASK.md and PROGRESS.md
first. Write the report to outputs/daily-review.md, update PROGRESS.md,
run the verification checklist, and stop if human review is required.
Do not modify any files except outputs/daily-review.md and PROGRESS.md.
Prueba con un intervalo corto (/loop 15m) mientras observas, y luego pasa a la cadencia real.
/loop vs /goal — resuelven problemas distintos:
/loopes impulsado por tiempo: la siguiente ejecución ocurre porque ha pasado tiempo (sondear un despliegue, revisar la carpeta cada mañana)./goales impulsado por condición: Claude sigue trabajando porque no se ha cumplido una condición de finalización (continuar hasta que las pruebas pasen).
Un loop programado necesita una política de parada — las ejecuciones que no encuentran nada deberían actualizar el estado silenciosamente o anotar "sin cambios significativos"; no generes un informe largo solo porque el loop se ejecutó. Reduce la carga de revisión; no crees una nueva bandeja de entrada.
Conclusión
La ingeniería de loops es la práctica de diseñar límites: qué inicia el loop, a qué puede acceder y qué puede cambiar Claude, cómo se registra el progreso, cómo se verifican los resultados y cuándo un humano debe revisar. Un loop fiable no depende de confiar en el modelo — depende de un control claro.
Construye primero el loop, hazlo autónomo después. Empieza con una tarea, un archivo de estado, una salida y una lista de verificación de verificación; ejecútalo manualmente; solo entonces prográmalo. La arquitectura — disparador → contexto → acción → verificación → estado → revisión — sigue igual tanto si el loop se mantiene local como si se conecta a GitHub, Slack o CI.
Fuentes principales: documentación de Claude Code sobre scheduled tasks / /loop y /goal. Mecánicas compuestas (PROGRESS.md, maker-checker, escalera de permisos) son síntesis de practicantes a partir de la guía fuente; el comportamiento de /loop y /goal fue verificado contra la documentación oficial el 2026-08-07.