Los cuatro tipos de bucle que todo agente necesita

Read in English → · 阅读中文版 →

Un bucle de agentes necesita una condición de parada antes que más herramientas. Sin ella, quema tokens, repite trabajo o actúa cuando nadie está mirando.

En junio escribí sobre bucles de agentes que se detienen solos: sistemas donde varios modelos verifican el trabajo del otro y limitan el costo. Ese artículo cubría un patrón: ejecutar más de un modelo, dejar que estén en desacuerdo y poner algo en el camino que lea ese desacuerdo. Este toma distancia para ver los tipos de bucle que hay debajo de los sistemas que ya construí.

La semana pasada, el equipo de Claude Code publicó “Getting started with loops”, y me dio un vocabulario que antes no tenía. Definen los bucles como “agentes que repiten ciclos de trabajo hasta que se cumple una condición de parada”, y los dividen en cuatro tipos según qué los dispara, qué los detiene y qué tipo de tarea encaja. Cuando mapeé mis sistemas actuales contra esa taxonomía, algo hizo clic. No estaba viendo un montón de automatizaciones personales raras. Estaba viendo una pila de patrones de bucle.

Aquí está la taxonomía, qué hace cada tipo y cuáles de los sistemas que ya lancé encajan en cada uno.

Los cuatro tipos

• Bucles por turnos. Tú das el prompt, el agente trabaja, tú revisas, tú vuelves a dar el prompt.
• Bucles por objetivo. El agente corre hasta que se cumple una condición explícita, o hasta que se llega a un tope de turnos.
• Bucles por tiempo. El trabajo corre en un horario o en respuesta a un evento.
• Bucles proactivos. Programados y autónomos. El agente actúa sin que tú estés en la sala.

Cada uno responde la misma pregunta de forma distinta: ¿quién decide cuándo parar?

Bucles por turnos: estos ya los usas

Cada prompt que envías empieza uno. El agente reúne contexto, actúa, revisa su propio trabajo y te devuelve el resultado. Después tú verificas y escribes el siguiente prompt. Tú eres la condición de parada.

Este es el bucle que todo el mundo corre sin pensarlo, y está bien para tareas cortas que no son parte de un proceso habitual.

Lo que construí: bucles de verificación multiagente

Mi último artículo cubría dos sistemas que encajan aquí.

opencode-fusion es panel más juez. Tres agentes, tres modelos, una pregunta. El panel responde, el juez los califica, y tú ves una sola respuesta sintetizada en lugar de tres transcripciones.

opencode-fusion ask \
  --panel "gpt-4o-mini,claude-3-5-haiku-20241022,gemini-2.0-flash-exp" \
  --judge "gpt-4o" \
  "Write a Python function to validate email addresses"

Los modelos están fijados a como estaban cuando lo construí. Cambia por lo que sea actual; al patrón no le importa.

agmsg bridge es mensajería persistente entre agentes. Un pequeño puente vigila un buzón SQLite compartido y entrega mensajes entre tres agentes, cada uno fijado a un proveedor distinto. Se mandan mensajes entre ellos hasta que convergen o llegan a un desacuerdo.

El puente no decide cuándo parar. Solo mueve mensajes. La condición de parada vive en las instrucciones de los agentes: responde con tu respuesta o pide una aclaración, y después de tres rondas, escala a un humano.

El camino de mejora para los bucles por turnos es mover tu verificación manual a un SKILL.md para que el agente pueda revisar su propio trabajo de principio a fin. Las verificaciones cuantitativas funcionan mejor. “Los tests pasan” es verificable. “Se ve bien” no lo es.

## Verification Loop

**Stop condition:** Tests pass OR max 3 attempts

1. Run `npm test`
2. If pass: complete
3. If fail AND attempts < 3: fix and retry
4. If fail AND attempts >= 3: escalate

Bucles por objetivo: criterios de salida deterministas

Los bucles por objetivo corren hasta que se satisface una condición específica, con un tope de turnos como red de seguridad. Defines “listo” desde el principio, y el agente compara su avance contra eso en lugar de preguntarte en cada ronda.

En Claude Code ese es el comando /goal. Algo así:

/goal Refactor the auth module to use JWT instead of sessions.
Done when: all tests pass, no linter errors, PR opened.

Lo que construí: seguimiento de objetivos en OpenClaw

OpenClaw trae create_goal y update_goal de fábrica:

create_goal({
  objective: "Migrate auth to JWT",
  token_budget: 50000
});

// Later...
update_goal({
  status: "complete",
  note: "Tests pass, PR #47 opened"
});

Lo uso para trabajo de varios pasos que abarca varias sesiones: implementar la funcionalidad, escribir los tests, actualizar la documentación. Los criterios de éxito van primero, el agente revisa después de cada paso, y el objetivo se cierra cuando se cumplen los criterios. El presupuesto de tokens es el tope de costo.

Bucles por tiempo: trabajo programado

Los bucles por tiempo corren en un horario o se disparan con un evento: un webhook, un cambio de archivo, un push. Claude Code te da primitivas con nombre aquí. /loop vuelve a correr un prompt localmente en un intervalo, como revisar un PR cada cinco minutos hasta que CI esté en verde. /schedule mueve la rutina a la nube para que corra sin tu máquina. Ten en cuenta que /schedule es una vista previa de investigación mientras escribo esto, así que espera que cambie.

Copilot CLI tiene comandos slash experimentales para el mismo patrón de programación local. /every o /loop programan un prompt, skill o comando slash programable recurrente dentro de la sesión actual. Dale un intervalo en segundos, minutos u horas. En la build que probé, omitir el intervalo crea un horario autorregulado: el CLI corre ahora y elige la siguiente corrida después de cada pasada.

/every 5m check PR #47 and tell me when CI is green
/every watch the deploy

Para trabajo diferido de una sola vez, /after programa un prompt una vez:

/after 30m check whether the preview deploy is live

Eso es programación a nivel de sesión. Para trabajo que necesita correr sin tu máquina o sin tu sesión de terminal, conecta copilot -p a GitHub Actions, cron, un manejador de webhooks o cualquier programador que ya sea dueño de la rutina.

Lo que construí: Dream Cycle y auto-consolidación

Dream Cycle es un escáner nocturno de investigación en IA. Cada noche a las 2:00 AM escanea arxiv de los últimos siete días, revisa GitHub trending buscando repos de IA/ML, filtra por relevancia con embeddings, genera propuestas de mejora a través de GitHub Copilot CLI, hace commit del resultado en git y manda un resumen a Telegram.

Condición de parada: investigación escaneada, propuestas generadas, commit en git exitoso.

Costo: corre sobre mi plan de Copilot actual. Las llamadas del CLI salen de los AI Credits incluidos cada mes, y esta carga se queda dentro de ellos. Si corres trabajos nocturnos más pesados, vigila tu uso de créditos; los bucles programados son justo el tipo de cosa que se come un presupuesto sin que te des cuenta.

Auto-consolidación es gestión de memoria. Corre cuando han pasado al menos 24 horas desde la última vez y se han acumulado al menos 5 sesiones. Lee el índice MEMORY.md, escanea los logs diarios recientes buscando señal nueva, la fusiona en archivos por tema, elimina duplicados y poda el índice para dejarlo bajo su límite de tamaño. La relación de compresión actual es de cerca de 9:1, convirtiendo 107 KB de logs diarios en 11.6 KB de archivos por tema.

La mecánica es la misma para ambos: el cron de OpenClaw levanta una sesión aislada, la sesión ejecuta y escribe la salida, y luego termina al completarse o por timeout. Ningún humano en el bucle.

Si estás empezando, arranca con monitoreo de solo lectura. Deja que un bucle programado observe y reporte durante una semana antes de dejarlo escribir algo.

Bucles proactivos: trabajo totalmente autónomo

Los bucles proactivos son trabajo programado sin ningún humano en tiempo real. Cada tarea dentro de la rutina termina cuando se cumple su objetivo, y la rutina misma sigue corriendo hasta que tú la apagas. El agente no solo reporta. Tría, arregla, abre el PR y te avisa después.

Lo que todavía no construí: triaje de issues más auto-arreglo

El plan: cada 6 horas, escanear los issues de GitHub en todos mis repos. Triarlos en P0/P1/P2. Para los P0, levantar un agente de arreglo que lea el issue, proponga una solución y se la pase a un agente de revisión que corra los tests y revise el estilo, y que abra un PR solo si se aprueba. Para los P1, comentar con pasos de reproducción y pedir logs. Para los P2, etiquetarlos como help wanted. Avisarme si aparece un bloqueador P0.

Por qué no está construido: los cambios de código autónomos necesitan bucles de verificación fuertes por debajo. Quiero tener el patrón de revisión de PR por un segundo agente lanzado y ganándose la confianza primero. Después se vuelve la compuerta dentro del bucle de triaje, no algo pegado como ocurrencia tardía.

Ese orden es justo el punto. Primero las capas de verificación, después la autonomía.

Cuándo no hacer un bucle

Antes de construir uno, cuatro preguntas.

¿La condición de parada está clara? Si no puedes definir “listo” en una sola frase, necesitas un problema más simple, no un bucle.

¿El costo está acotado? Leer el desacuerdo nunca debería costar más que el bug que atrapa. Pon presupuestos de tokens, corre modelos baratos para las primeras pasadas y escala a modelos caros solo cuando los baratos no se ponen de acuerdo.

¿Puede un humano verificar la salida? Si tu respuesta es “no sé cómo revisar esto”, el agente tampoco va a saber. Las verificaciones cuantitativas le ganan a las verificaciones a ojo.

¿Esto es de verdad trabajo recurrente? Las tareas de una sola vez no necesitan bucles. Simplemente haz el trabajo.

Lo que te da la taxonomía

Los cuatro tipos comparten el mismo esqueleto: un disparador, un ciclo de trabajo, una condición de parada y verificación. La diferencia es quién decide cuándo parar. En los bucles por turnos eres tú. En los bucles por objetivo es el agente, comparado contra criterios explícitos. En los bucles por tiempo es el horario. En los bucles proactivos es el agente otra vez, después de actuar por su cuenta.

Tener nombres para eso cambia cómo construyes. “Construí una cosa que se revisa a sí misma” se vuelve “construí un bucle de verificación por turnos con consenso de panel y un tope de escalamiento de tres rondas”, y la segunda frase es reutilizable. Puedes levantar el patrón en una plantilla de skill, explicarle el tradeoff a alguien del equipo y ver el hueco en tu propia pila. Hoy tengo bucles por turnos y por tiempo corriendo. Los proactivos son lo que sigue, y ahora sé exactamente qué capa de verificación falta antes de que sea seguro lanzarlos.

Una nota antes de que construyas esto

Una advertencia antes de que programes nada. Un bucle por turnos falla frente a ti. Un bucle por tiempo falla a las 2 AM sin nadie mirando, y uno proactivo actúa sobre la falla. Empieza en solo lectura, mantén los presupuestos ajustados y no le des acceso de escritura a un bucle hasta que lo hayas visto equivocarse unas cuantas veces.

Publicado originalmente en X.