El loop no es lo que pensás (y por eso tus agentes no convergen)

Es lo que la mayoría imagina cuando dice "agente": llamás una tool, leés el resultado, decidís el próximo paso, repetís hasta que no quedan más tool calls. Addy Osmani lo llama el inner execution loop. Es el loop más chico que podés diseñar.

Itera sobre pasos dentro de una misma tarea. Termina cuando el entorno devuelve una respuesta: el output del test, la API response, el contenido del archivo. El humano aparece en los bordes — aprueba planes, revisa resultados. No está en el medio del loop.

El problema: el agente también termina cuando él decide que terminó, haya o no resuelto la tarea. Y la primera solución que encontró el campo fue envolver este loop en otro que no le crea al agente.

Geoffrey Huntley lo bautizó Ralph loop, y fue el primer loop con nombre propio que se mencionó desde el escenario principal de la AIEWF. Funciona así: reiniciás el agente contra la misma spec, una y otra vez, con un contexto completamente fresco en cada iteración. Exactamente una tarea por loop.

Lo que parece desperdicio es la gracia: al recargar la spec completa cada vez, evitás el context rot y los compaction events que degradan silenciosamente las sesiones largas. El humano escribe la spec y juzga si está hecho. Su otro trabajo, dice Geoffrey, es mirar el loop, detectar patrones de falla y arreglarlos para siempre.

Este loop itera sobre un artefacto. Termina cuando la spec se cumple y los tests pasan. Si hacés zoom out, aparece el loop de arriba.

Tereza Tížková de Factory lo definió como "el loop completo, todo el lifecycle de desarrollar software con autonomía". Zach Lloyd de Warp se puso más específico: triage, spec, implementación, review, verificación, deploy, monitoreo. Siete etapas.

Zach dice que la ingeniería de software se convierte en ingeniería de fábricas. Que vas a construir la cosa que construye el producto. Warp lo dogfoodea: pusieron su propio repo open-source bajo control de Oz, su plataforma factory, y subieron la tasa de merge automático de PRs del 20% al 60%.

Anthropic corre el mismo experimento internamente: el 65% del código de su equipo de producto ya lo genera Claude Tag. Mike Krieger lo describió como "no arreglá este bug, sino hacete cargo de esta parte del codebase, monitoreá este canal de feedback y levantá tareas solo".

El execution loop y el task loop tienen condiciones de salida definidas. El product loop itera sobre un codebase y su backlog, continuamente, y sus señales de cierre vienen de afuera del código: issues nuevos, logs de producción, feedback de usuarios.

Roland Gavrilescu de Introspection lo llama autoresearch: el loop interno es tu sistema primario haciendo trabajo para usuarios, y el loop externo estudia y mantiene el sistema primario. Itera sobre prompts, harnesses, modelos y los propios evals. Su frase: "el loop es el producto".

El caso mínimo es el autoresearch de Andrej Karpathy de marzo 2026: ~630 líneas de Python que corrieron 50 experimentos (hipótesis → editar → evaluar) en una GPU en una noche. El caso shipped es Meta Brain2Qwerty v2: agentes modificaron iterativamente el codebase para inventar mejores arquitecturas de decoding. El caveat de Meta: las configuraciones finales de training las seleccionó un humano a mano.