AgentLoop

AgentLoop arranca un proceso de motor nuevo para cada worker y cada sesión de crítico, así que ningún historial de chat previo los acompaña. Esto evita la podredumbre de contexto, la acumulación de supuestos obsoletos que vuelve poco fiables los chats largos. La memoria duradera es el propio proyecto más los arreglos concretos que escribe el crítico, lo que evita quemar tokens releyendo una conversación que no deja de crecer.

Pones tu definición de terminado en GUIDELINES.md. Un crítico nuevo lee ese archivo cada ciclo junto a la salida del worker y los archivos del proyecto. La última línea del crítico es un contrato estricto: debe acabar en PASS, FAIL con notas de arreglo o CONTINUE. Un FAIL se convierte en instrucciones inyectadas para el siguiente worker, así que la retroalimentación se transforma en acción en vez de un comentario que tienes que reenviar a mano. En la propia evaluación del proyecto, un crítico nuevo encontró un defecto mixto de decodificación porcentual después de que las nueve pruebas hubieran pasado.

El progreso vive en PLAN.md y STATE.md, no en una conversación. Un worker lee el plan y el estado, hace un incremento, actualiza el estado y sale. Como la memoria está en archivos, el bucle se mantiene acotado y es más fácil dejarlo desatendido. También significa que puedes leer los mismos artefactos con los que trabajan los agentes y ver exactamente qué cambió en cada paso.

Cada ciclo, veredicto, transcripción, costo y entrega de archivos aparece en un panel local. Puedes cancelar una ejecución desde ahí en vez de andar cazando un proceso, y puedes preguntarle el estado a ChatGPT mediante un puente MCP. Sin adivinar. Para quien ha intentado depurar una ejecución desatendida de un agente a posteriori, tener la línea de tiempo registrada marca la diferencia entre arreglar un problema y suponer qué pasó.

AgentLoop ejecuta el CLI de Codex y Claude Code como motores intercambiables. Eliges uno por bucle desde el panel, o por tarea a través del puente. El proyecto mantiene la planificación separada de la ejecución local, y la hoja de ruta apunta a preguntas bidireccionales del agente y bucles de investigación para lo próximo.

Para proyectos dentro de un árbol de trabajo de git, el checkpointing automático viene activado por defecto, así que el daemon puede confirmar el progreso a medida que se completan los ciclos. Los fallos repentinos, como una tarea atascada que alcanza su límite de reintentos, no borran el trabajo ya hecho. Recuperarse está a un comando de git, no a una tarde perdida. Eso importa en las ejecuciones nocturnas.

Un bucle es secuencial a propósito. Las tareas independientes en cola pueden correr hasta un límite de concurrencia, pero un bucle nunca se convierte en un enjambre paralelo que corretea por el mismo proyecto. Es deliberado. Los presupuestos también tienen tope. maxCycles va de 1 a 50 y por defecto es 3, y taskRetries limita los fallos consecutivos antes de que una tarea se marque como bloqueada y se omita.