Introduccion
En el mundo de los AI agents de Silicon Valley aparecio otro concepto nuevo: Loopcraft.
Mi primera reaccion fue: ¿no es simplemente meter un agent dentro de while true? Hace unos anos lo llamabamos Agent Loop. Luego se volvio Workflow y Harness Engineering. Ahora aparece Loopcraft. El mundo AI no deja de inventar nombres.
Pero al seguir las conversaciones recientes de Peter Steinberger, Boris Cherny, responsable de Claude Code, y Andrej Karpathy sobre agent loops, creo que esta vez si hay un cambio real.
Peter Steinberger lo dijo asi:
You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.
Es decir, ya no deberias escribir prompts manualmente para un coding agent una y otra vez. Deberias disenar un loop que haga ese prompting por ti.
Boris Cherny dijo algo parecido:
I don’t prompt Claude anymore. I write loops. The loops do the work.
Karpathy expreso una idea cercana al presentar Autoresearch: si una persona todavia tiene que revisar cada resultado, decidir el siguiente paso y dar otra instruccion al agent, esa persona se convierte en el cuello de botella de todo el sistema.
Juntas, estas ideas senalan un cambio de nivel de abstraccion:
Antes:
Humano -> Prompt -> Agent -> Resultado
Ahora:
Humano -> Disena el loop
↓
Descubrir tarea -> Ejecutar agent -> Verificar automaticamente -> Reintentar si falla -> Guardar estado -> Seguir ejecutando
Mi definicion mas corta es: Prompt Engineering optimiza una interaccion. Loopcraft optimiza el sistema entero que se ejecuta repetidamente.
Loopcraft no se centra solo en como hacer bien una tarea aislada. Pregunta cosas como:
- Quien inicia la siguiente tarea;
- como sabe el agent que debe hacer;
- quien revisa la salida;
- como se convierte un fallo en feedback util;
- si conviene reintentar, cambiar de estrategia o escalar a una persona;
- como se conserva el estado entre sesiones;
- como las lecciones de muchas ejecuciones mejoran el sistema.
Este articulo responde tres preguntas:
- Que es Loopcraft y por que empezo a recibir atencion;
- en que se diferencia de Agent Harness;
- si un desarrollador comun puede construir un loop pequeno hoy.
1. Por que se habla menos de prompts y mas de loops
Durante los ultimos dos anos, usar un coding agent normalmente se veia asi:
Decirle al agent que hacer
-> Esperar los cambios de codigo
-> Revisar el resultado
-> Decirle que esta mal
-> Dejar que el agent continue
-> Revisar otra vez
El modelo ya puede escribir codigo, buscar archivos y ejecutar tests. Pero el proceso completo sigue siendo dirigido paso a paso por una persona.
Despues de cada ronda, el agent se detiene y espera la siguiente instruccion.
En la superficie, la persona esta usando el agent. Desde otro angulo, la persona tambien actua como scheduler, maquina de estados y verifier del sistema de agents.
Por eso, aunque el modelo sea rapido, la persona no puede irse. Las funciones moviles de supervision asincrona que estan lanzando muchos productos de agents intentan aliviar justamente este cuello de botella.
Ese es el problema detras del reciente loop discourse: no automatices solo un paso del trabajo; disena tambien el sistema que descubre tareas, las asigna, las verifica y decide como continuar.
Por ejemplo, arreglar un fallo de CI antes podia verse asi:
Veo que CI fallo -> Abro Codex -> Copio el log de error -> Le pido que lo analice -> Reviso el diff -> Le pido que ejecute tests -> Confirmo que todo esta verde -> Creo el PR manualmente
Dentro de un loop, puede verse asi:
Evento de CI fallido -> Leer logs automaticamente -> Decidir si el problema es seguro para automatizar -> Iniciar un agent en un worktree aislado -> Modificar codigo -> Ejecutar tests y lint -> Un segundo verifier revisa el diff -> Crear PR si pasa -> Notificar a una persona si no puede continuar
Lo que se automatiza de verdad no es solo editar codigo. Es el circuito cerrado alrededor de la edicion de codigo.
Por eso Loopcraft no es una nueva capacidad de modelo ni un framework especifico.
Es mas bien una disciplina de diseno de sistemas agenticos: organizar ejecucion de tareas, verificacion de resultados, eventos, persistencia de estado y mejora del sistema en loops que pueden anidarse.
2. Es Loopcraft realmente nuevo?
El nombre es nuevo. Las piezas tecnicas no lo son.
Ya teniamos:
- loops Reason-Act-Observe para agents;
- workflows y maquinas de estado;
- tests automaticos y CI/CD;
- tareas programadas y sistemas event-driven;
- colaboracion multi-agent;
- LLM-as-a-judge;
- Reflexion y Self-Refine;
- memoria de largo plazo;
- experimentacion automatica y hill climbing.
Incluso el Ralph Loop mas simple es basicamente invocar un coding agent repetidamente:
while true; do
claude "Lee la tarea y el progreso actual, y continua el trabajo"
done
3. Agent Harness vs. Loopcraft
Aqui es donde los terminos se confunden con mas facilidad.
Durante el ultimo ano, Agent Harness ya se habia vuelto un concepto popular.
La definicion de Anthropic es clara: un harness es el sistema que permite que un modelo trabaje como agent, incluyendo contexto, uso de herramientas, permisos, entorno, gestion de estado y devolucion de resultados.
En simple: Harness responde en que entorno trabaja este agent?
Loopcraft responde otra pregunta: cuando se inicia este agent, por que sigue ejecutandose, quien revisa el resultado y que debe pasar en la siguiente ronda?
Una analogia simplificada:
Model: el cerebro del trabajador
Tools: las herramientas en sus manos
Harness: su puesto y entorno de trabajo
Loop: el ritmo de produccion, control de calidad y asignacion de tareas
Loopcraft: como disenar y superponer todo el sistema de loops de produccion
En la practica, la frontera no es absoluta.
Un harness maduro para tareas largas ya incluye reintentos, verificacion y traspaso de estado. Un loop tambien depende del harness para tener herramientas y entorno de ejecucion.
Prefiero separarlos por foco:
| Concepto | Pregunta principal |
|---|---|
| Prompt Engineering | Que instruccion debe ver el modelo en esta ronda? |
| Context Engineering | Que informacion debe ver el modelo ahora? |
| Tool Engineering | Que acciones puede ejecutar el agent? |
| Harness Engineering | Como ocurre de forma fiable una ejecucion del agent? |
| Loopcraft | Como se disparan, verifican, conectan y mejoran muchas ejecuciones? |
Loopcraft no reemplaza a Harness.
De hecho, sin un harness estable, un loop solo fabrica errores de forma automatica y continua.
4. Loopcraft no es un loop, sino capas de loops
LangChain despues dividio Loopcraft en cuatro capas practicas. La division me parece util.
Capa 1: Agent Loop
La capa interna es el agent loop que ya conocemos:
El modelo razona
-> Llama una herramienta
-> Lee el resultado de la herramienta
-> Sigue razonando
-> Se detiene cuando cree que termino
Por ejemplo, un agent de documentacion puede:
Leer un issue -> Buscar en el repositorio -> Editar Markdown -> Revisar links -> Crear un PR
Capa 2: Verification Loop
Que un agent diga "done" no significa que la tarea este terminada. Por eso conviene envolverlo con una capa de verificacion:
Agent ejecuta
-> Verifier revisa
-> Si falla, devuelve feedback concreto
-> Agent ejecuta otra vez
-> Repetir hasta que pase o se agote el presupuesto
El verifier puede ser una suite de tests, type check, lint, validacion de schema, etc.
Un principio importante: intenta no dejar que quien escribe la respuesta tambien califique su propio examen.
Capa 3: Event-driven Loop
Una vez que hay ejecucion y verificacion, el siguiente paso es quitar el inicio manual.
Las tareas pueden dispararse por eventos reales. El agent deja de ser solo una herramienta de chat y pasa a ser un componente de backend dentro de un sistema de negocio.
Evento
-> Una regla deterministica decide si debe manejarse
-> Iniciar agent
-> Verificar resultado
-> Actualizar el sistema real
Capa 4: Hill-climbing Loop
Las primeras tres capas automatizan el trabajo.
La cuarta empieza a automatizar como el trabajo mejora.
Cada ejecucion del agent deja una traza:
- que tarea recibio;
- que herramientas llamo;
- donde fallo;
- por que lo rechazo el verifier;
- cuantos tokens uso;
- si una persona tuvo que intervenir.
Un sistema externo puede analizar esas trazas periodicamente:
Recolectar registros de muchas ejecuciones
-> Identificar patrones frecuentes de fallo
-> Ajustar prompts, tools, skills o verifiers
-> Probar de nuevo en un eval set
-> Actualizar el harness si pasa
Esta capa es donde Loopcraft se vuelve mas valioso.
Un loop ordinario repite trabajo. Un hill-climbing loop cambia el sistema que produce el trabajo.
Loop ordinario:
Fallo -> Intentar otra vez
Loop de mejora:
Fallo -> Analizar por que fallo
-> Modificar prompts, herramientas o reglas de verificacion
-> Hacer mas fiables las ejecuciones futuras
La flecha del loop externo no solo vuelve al inicio de la tarea. Entra en el agent y cambia el loop interno.
Alli empieza el efecto compuesto.
5. Autoresearch de Karpathy es el ejemplo mas limpio hasta ahora
Autoresearch de Karpathy es un buen ejemplo concreto para entender Loopcraft.
El proyecto es simple en concepto:
Agent propone una mejora de entrenamiento
-> Modifica train.py
-> Ejecuta entrenamiento durante cinco minutos fijos
-> Lee la metrica val_bpb
-> Conserva el cambio si mejora
-> Revierte si empeora
-> Empieza el siguiente experimento
Puede ejecutar unas 12 pruebas por hora sin intervencion humana. Durante una noche, puede acercarse a 100 experimentos.
Lo inteligente no es un prompt especialmente complejo. Lo inteligente es que Karpathy transformo el problema en un entorno ideal para optimizacion en loop:
- el agent solo puede modificar un archivo;
- la metrica de evaluacion es fija;
- cada experimento tiene tiempo fijo;
- los resultados pueden compararse automaticamente;
- los cambios fallidos pueden revertirse;
- Git registra toda la historia experimental;
- el codigo de verificacion no puede ser modificado por el agent.
Ese es el cambio central de Loopcraft: la persona deja de hacer directamente la tarea y pasa a disenar un sistema que puede hacerla, verificarla y mejorarla repetidamente.
6. Como construir tu propio loop minimo
Autoresearch es un entorno especial. Un desarrollador comun puede empezar con algo mas simple:
Recibir automaticamente un issue pequeno, intentar arreglarlo, crear un PR cuando pasen los tests y reintentar con feedback cuando falle.
No empieces con orquestacion multi-agent. Un loop minimo solo necesita seis partes:
- Trigger: que evento inicia la tarea, por ejemplo un fallo de CI, una tarea programada o un issue con una etiqueta concreta.
- Goal: que cuenta como terminado, idealmente algo que pueda convertirse en tests, lint, type check u otra condicion verificable por maquina.
- State: guardar numero de intentos, razon del fallo y progreso actual en un archivo o base de datos, no solo en el contexto del chat.
- Worker: ejecutar el coding agent en un worktree o contenedor aislado para no contaminar la rama principal ni otras tareas.
- Verifier: priorizar tests, reglas y analisis estatico. Usar un LLM reviewer solo para partes dificiles de formalizar.
- Budget: limitar intentos, tiempo y coste. Escalar a una persona cuando haya operaciones de alto riesgo.
El flujo completo puede simplificarse asi:
for attempt in range(3):
result = run_agent(goal, load_state())
verdict = verify(result)
save_state(result, verdict)
if verdict == "passed":
create_pull_request()
break
if verdict != "retryable":
notify_human()
break
No importa tanto si usas Claude Code, Codex, GitHub Actions, Bash o Python.
Lo importante es disenar con claridad esta cadena:
Trigger -> Ejecutar -> Verificar -> Feedback -> Reintentar o salir
Si una tarea tiene objetivo claro, feedback fiable, estado recuperable y condicion de parada, ya tienes un loop minimo.
7. Trampas comunes de Loopcraft
Trampa 1: confundir reintento infinito con autonomia
Ejecutar repetidamente no equivale a mejorar.
Si el agent no recibe feedback nuevo, repetir diez veces suele significar gastar diez veces mas tokens para cometer errores parecidos.
Trampa 2: dejar que el agent cambie su propio examen
El agent que ejecuta no deberia modificar libremente tests, metricas de evaluacion, presupuestos de tiempo, limites de permisos o prompts del verifier.
Si lo hace, tal vez no este mejorando la tarea. Tal vez solo este haciendo que "pasar" sea mas facil.
Trampa 3: empezar con muchos agents
Varios agents no crean inteligencia automaticamente. Primero crean mas coste de tokens, conflictos de archivos, trabajo duplicado y problemas de sincronizacion de estado.
Haz funcionar un worker, un verifier y un camino de estado persistente antes de agregar paralelismo.
Trampa 4: medir que tan ocupado esta el agent
Numero de agents, tiempo de ejecucion, tokens y llamadas a herramientas no son el valor final.
Lo que importa es progreso verificado por unidad de coste.
Ejemplos: tasa de issues resueltos automaticamente, coste promedio por PR valido y proporcion de escalamiento humano.
Trampa 5: cuanto mas fluido el loop, mas facil dejar de entender
Este es el riesgo que mas me preocupa.
Cuando un agent puede escribir codigo, probarlo, arreglarlo y crear un PR automaticamente, las personas pueden caer en mirar solo el check verde final.
Pero cuanto mas rapido produce codigo el sistema, mas rapido puede caer la comprension humana del propio sistema.
Loopcraft no deberia convertirse en una excusa para dejar de pensar. En realidad sube el nivel de comprension que se exige a la persona.
Cierre
Cada vez siento mas que la ingenieria de agents esta viviendo un cambio de abstraccion.
Primero discutimos prompts. Luego pasamos a contexto, herramientas, memoria y harnesses.
Ahora el foco se mueve otra vez hacia fuera: como poner una ejecucion de agent dentro de un ciclo mas amplio de tareas, verificacion y mejora.
Sigo siendo esceptico sobre sacar por completo a las personas del loop.
Pero estoy de acuerdo con una idea:
No arregles solo el resultado actual producido por el agent. Empieza tambien a arreglar el sistema que sigue produciendo esos resultados.