← Todas las noticias

Loops de agentes: qué quedó después del hype del Ralph loop

Meter un agente en un while-true fue meme y después fue movimiento. Pasado el entusiasmo quedó lo útil: loops con criterio de parada, loops con verificación y loops con presupuesto.

Leonardo Dias agentesdevrelentless

En 2025, Geoffrey Huntley bautizó Ralph loop a una idea vergonzosamente simple: meter un agente de código dentro de un while true de bash y dejarlo correr. El nombre viene de Ralph Wiggum, de Los Simpson — persistencia alegre e ingenua. Demostró el punto dejando que un agente construyera un lenguaje de programación, compilador incluido, en una corrida larga sin supervisión.

El truco prendió. Fue post, fue charla y terminó siendo paquete — Vercel Labs publicó un ralph-loop-agent para el AI SDK. Y como todo truco que prende, pasó por la fase en que era la respuesta para todo: “no hace falta orquestar nada, es solo correrlo en loop”.

Mi lectura, un año después: el hype se enfrió, y qué bueno. Porque lo que quedó es la parte útil — y la parte útil nunca fue el while true. Es lo que pones adentro.

Lo que el Ralph loop acertó de verdad

Tres cosas, y las tres siguen en pie.

Contexto fresco en cada iteración. Cada vuelta abre un proceso nuevo, con ventana limpia. Eso ataca de frente la degradación de contexto largo, que es el modo de falla más común de los agentes de código. Es el mismo principio con el que construimos Relentless: la memoria entre iteraciones no vive en una conversación infinita, vive en git.

Memoria externa en disco. El estado sale de la cabeza del agente y aterriza en archivos, commits y artefactos — cosas que sobreviven al proceso y que un humano puede leer.

La persistencia barata le gana a la genialidad cara. Veinte intentos mediocres con verificación entre ellos suelen ganarle a un intento brillante sin ninguna verificación. Eso es estadística, no filosofía.

Dónde el loop tonto quema plata

El loop nunca fue el problema. El problema es un loop que no responde ninguna de las tres preguntas que importan: cuándo paro, cómo sé que mejoró y cuánto puede costar esto.

Sin criterio de parada, el agente oscila. Vi un loop pasarse la madrugada cambiando una abstracción por otra y volviendo a la primera — commit A, commit B, commit A otra vez — cada vuelta con contexto limpio, cada vuelta convencida de que estaba arreglando algo. El contexto fresco corta para los dos lados: el agente no recuerda que ya intentó eso.

Sin verificación, el loop optimiza apariencia. El agente “termina”, el loop pregunta si está listo, y el agente dice que sí porque el texto que acaba de escribir parece una conclusión. La autoevaluación dentro de un loop es una máquina de fabricar confianza sin fabricar aciertos.

Sin presupuesto, un error de criterio se transforma en factura. Dejar un agente corriendo sin techo de tokens, tiempo o iteraciones es la versión 2026 de olvidarse un cluster prendido el fin de semana. Con la diferencia de que el cluster al menos no hace commit.

Loops con criterio de parada: loop-until-dry

El patrón que más uso es el que llamo loop-until-dry. No corres hasta que esté “listo”: corres hasta que el loop se seque.

Una ronda está seca cuando no produce cambio material: ningún archivo relevante tocado, ninguna tarea cerrada, ningún test nuevo pasando. Una ronda seca sola no decide nada, puede ser mala suerte. Dos o tres rondas secas seguidas — la K de tu criterio — significan que el trabajo se acabó de verdad. Ahí paras.

El detalle que hace la diferencia es medir la sequía en el artefacto, no en la narración del agente. Un diff vacío está seco. “Creo que la implementación ya está completa” no lo está.

Loops con verificación: generar, refutar, quedarse con lo que sobrevive

Un loop bueno no es generar-y-repetir, es generar-e-intentar-tumbar. Cada iteración se vuelve un pequeño proceso adversarial: un paso produce el artefacto y otro paso — con contexto propio y objetivo invertido — intenta refutarlo. Solo entra al repositorio lo que sobrevivió al intento de refutación.

Ciclo de iteración: generar, refutar y la pregunta “¿sobrevivió?”. Lo que sobrevive se acepta, lo que no vuelve al inicio, y el loop entero para cuando K rondas seguidas salen secas. LOOP CON VERIFICACIÓN generar refutar ¿sobrevivió? acepta no próxima ronda K rondas secas para

La iteración solo entrega lo que sobrevive al intento de refutación — y el loop entero para cuando K rondas seguidas salen secas.

Eso cambia lo que el loop optimiza. Sin refutación, converge hacia lo que parece terminado. Con refutación, converge hacia lo que resiste. Y el refutador más barato casi nunca es un LLM: tests, compilador, type checker, linter y validación de esquema tumban más cosas por dólar gastado que cualquier prompt de revisión.

Es la misma verificación adversarial que describí en grafos de agentes, aplicada en el tiempo en lugar de en el espacio.

Loops con presupuesto: techos declarados antes de arrancar

Todo loop que corre sin supervisión necesita tres techos declarados antes de la primera vuelta: máximo de iteraciones, máximo de tokens (o costo) y máximo de tiempo de reloj. Y necesita una conducta de salida para cuando los toque: escribir un reporte del estado, no desaparecer a mitad de camino.

Tres medidores de presupuesto del loop: iteraciones, tokens y tiempo, con un techo común punteado. Al tocar el techo, el loop escribe un reporte del estado y para. PRESUPUESTO DEL LOOP iteraciones 12 / 20 tokens 1.2M / 2M tiempo 38m / 60m techo al tocar el techo: reporte y para

Tres techos declarados antes de la primera vuelta. Al tocar cualquiera, el loop escribe el estado y para — no desaparece a mitad de camino.

El presupuesto también es una decisión de arquitectura, no solo de contabilidad. Cuando sabes cuánto puede costar una tarea, eliges el modelo por nodo en vez de usar el más caro en todo. Eso fue lo que terminó siendo el Smart Auto Mode de Relentless: elegir el modelo por la complejidad real de la tarea y no por miedo a equivocarse. El ahorro no viene de usar un modelo peor — viene de dejar de gastar un modelo de frontera en renombrar una variable.

El loop es el motor, el grafo es el mapa

“¿Loops o grafos?” es un debate falso, y le costó un año a mucha gente buena.

El grafo es topología: quién depende de quién, qué puede correr en paralelo, dónde están las barreras y los verificadores. El loop es dinámica: cuántas veces un nodo reintenta antes de rendirse, y qué hace avanzar al conjunto hasta que se seque.

Se componen en dos niveles. Dentro del nodo, el loop es local — intenta, verifica, intenta de nuevo, con presupuesto propio y criterio de parada propio. Afuera, el loop es global: el grafo entero vuelve a correr mientras haya trabajo, y para cuando K vueltas seguidas salen secas. Un loop sin grafo es fuerza bruta cara. Un grafo sin loop es una cinta que se traba en el primer nodo terco y espera a un humano.

Un año después del meme, eso es lo que quedó del Ralph loop, y es bastante. No la promesa de que la persistencia reemplaza a la arquitectura, sino la prueba de que la persistencia estructurada es sorprendentemente fuerte. El while true era la parte fácil. Criterio de parada, refutación y presupuesto son el trabajo.

Si alguna vez dejaste un agente corriendo toda la noche y amaneciste con una factura y ningún avance, el problema no fue el loop. Fueron las tres preguntas que faltaban. Hablá con nosotros o mirá nuestra consultoría agéntica — y si quieres ver el motor, Relentless es open source.