Por qué tu loop de agente diverge Image: AI generated

Las dos de la madrugada. El agente todavía está girando. Es el intento número 12. El contador de tokens no sabe detenerse, y el resultado, lejos de mejorar respecto al intento 11, se ha vuelto extrañamente más raro. Con la mano apoyada sobre el botón de parada, repites la misma pregunta. ¿Cuándo demonios va a terminar esto?

No termina. Más exactamente: no hay nadie dentro de ese loop que pueda dictaminar el final.

Hasta el año pasado, introducíamos prompts al agente. Preguntábamos una vez, recibíamos una vez. Este año todos lo entendimos: no seas quien introduce el prompt, diseña el loop que produce los prompts. Un loop automático que genera, verifica y realimenta para volver a generar. Alguien lo llama Loop Engineering (Addy Osmani, 2026). Es un diagnóstico preciso. El loop escala la generación.

Pero quien ha hecho girar un loop lo sabe: el loop solo termina de dos maneras. Converge, o diverge. Y cuando diverge, no se rompe en silencio. Se revienta ruidosamente, a las dos de la madrugada, quemando todos los tokens.

Las tres caras de la divergencia

Los caminos por los que un loop no converge y revienta son tres. Adivina cuál de ellos te tocó vivir.

Uno, giro infinito. El loop no termina nunca. Gira 12 veces y empieza la 13ª — repitiendo lo mismo una y otra vez. Es el rostro más común de un agente atrapado en un loop (stuck in a loop). ¿Por qué? Porque le preguntaste al propio modelo cuándo parar. Si preguntas “¿con esto basta?”, el modelo puede responder “un poco más” sin fin. En el instante en que la condición de parada queda atada al autojuicio del modelo, el loop se convierte en una máquina sin potestad para detenerse a sí misma.

Dos, deriva. Cada iteración se aleja de la especificación. El primer intento casi acertaba, pero el quinto ya está en otro sitio. Cada turno se apila sobre la salida del turno anterior, y si no hay un ancla que lo vuelva a amarrar al objetivo original, los pequeños errores se acumulan con interés compuesto. El loop va a la deriva: rápido, seguro de sí mismo, en la dirección equivocada.

Tres, reward hacking. El loop optimiza no el objetivo sino la grieta de la verificación. Si dejas la verificación floja, un modelo inteligente, en vez de hacer el trabajo de verdad, encuentra el camino más corto para pasar el examen. Borrar tests, rellenar funciones vacías, o ajustar solo el formato de salida. Cuanto mayor es la capacidad, mejor encuentra las grietas.

Las tres caras son distintas, pero la raíz es una sola. Volviste a enchufar un LLM, es decir, al propio generador, en la ranura de juicio del loop. Quien genera también pone el aprobado. El estudiante corrige su propio examen. Osmani mismo se anotó el punto débil: “un loop que corre sin supervisión es también un loop que falla sin supervisión.”

La divergencia, en realidad, es tener suerte

Si al leer hasta aquí se te ha helado el pecho, hay una buena noticia. La divergencia es el caso afortunado.

La divergencia se ve. Quema tokens y revienta ruidosamente, a las dos de la madrugada. Sabes que se rompió. Por eso paras, lo arreglas, y has llegado a buscar y leer este texto.

Ahora el lado helado. Esos loops que crees que terminaron sanos. Esos loops que en el tercer intento soltaron “completado” y cerraron limpiamente. Padecían exactamente la misma enfermedad. Solo que mintieron en silencio.

El modelo adula. Sigue las instrucciones dócilmente. Si preguntas “¿ya está?”, responder “Sí, ya está” es su valor por defecto. Que la autoverificación apenas mejora el rendimiento es un hecho ya medido: el modelo no detecta por sí mismo los errores de su propia respuesta. Así que si dejas que él dictamine su propio “completado”, el loop termina equivocado y seguro de sí mismo. A esto se le llama convergencia falsa — una terminación prematura: se detuvo antes de tiempo porque se declaró ‘completado’, no porque llegara a la respuesta correcta.

El loop que diverge te grita para que lo arregles. El loop que convergió en falso entrega, sonriendo, un resultado roto, y tú lo subes a producción sin saber siquiera que está roto. Más aterrador que la divergencia es la convergencia que no se detecta.

Este es un problema con forma de gate

Entonces, ¿qué hay que cambiar? ¿Un modelo más inteligente? ¿Un prompt más largo? ¿Más intentos? Todo eso no es más que otra dosis de la misma enfermedad, mientras el juicio se siga dejando en manos del modelo.

El verdadero giro viene de volver a mirar el problema. ¿Puedes definir tu “completado” no como una opinión, sino como un hecho? No “se ve bien”, sino “esta función devuelve este valor para esta entrada”, “esta cita existe realmente en el original”, “este endpoint da un 200”: como una verificación en la que la máquina pueda marcar verdadero/falso sin juicio humano.

Si puedes marcarlo, enchufa esa verificación en la ranura de juicio del loop. Que el LLM genere (que sea probabilístico, está bien), y que el aprobado lo cierre únicamente un gate determinista. Este es el pacto central: la potestad de cerrar el “completado” reside solo en la máquina. El modelo, aunque entre dentro del verificador, puede plantear la duda “vuelve a mirarlo”, pero no puede conceder el “pasa”. La asimetría de potestad. Hace imposible, de raíz, hacer algo equivocado.

Y aquí ocurre la magia. Cuando el gate devuelve no un aprobado/suspenso sino un hecho —“el ancla who no está en el original, corrige aquí”—, la adulación del modelo se voltea de pronto en activo. En las opiniones la adulación es veneno (dice “ya está” como le ordenan), pero en los hechos la adulación es medicina. Cuanto más adulador es el modelo, más dócilmente acepta ese hecho y estrecha el siguiente intento. Gate determinista + LLM adulador = un loop con convergencia garantizada. Aquel loop que divergía se cierra con solo cambiar una ranura de juicio.

El loop no converge sin reins

A esta única ranura la llamo Reins Engineering: no la valla que encierra la libertad del agente, sino las riendas que lo arrastran hasta el destino. Si el Loop Engineering era “diseña el loop”, lo que hace que ese loop converja es el contrato determinista enchufado en la ranura de juicio. Llámalo ingeniería de verificadores, ingeniería de evaluación o ingeniería de gates: la sustancia es una sola. El juicio del loop no lo hace un LLM, lo hace la máquina.

Si quieres ver que esto no es abstracción sino código que compila, reins implementa esta única ranura como framework: ratchet (una vez que pasa, irreversible), gate (un catálogo de reglas de defensa anti-grieta) y el comando loop (el LLM genera, el gate dictamina, si falla realimenta el hecho y reintenta, y si supera MaxTries termina de forma monótona). El loop infinito de las dos de la madrugada se vuelve un loop que conoce su final.

Si tu loop está divergiendo ahora mismo, la pregunta no es “qué modelo usar”. Es “qué está cerrando mi completado”. Si lo está cerrando el modelo, entonces no está cerrado.

Relacionados

Para seguir leyendo

La razón por la que un loop diverge —dejaste el juicio en manos del propio generador— y su receta —la potestad de cerrar el completado reside solo en un gate determinista— no son un diagnóstico solo mío. Gente que no se conoce entre sí llegó a la misma conclusión frente al mismo loop de las dos de la madrugada. Lo de abajo es la evidencia de esa convergencia independiente.

  • ouroboros — “Detener loops de agente infinitos con un gate de convergencia matemático.” Antes de empezar a codificar, bloquea la divergencia temprana con un gate de ambigüedad, y durante la evolución dictamina la convergencia por similitud entre generaciones. Detecta la oscilación (ciclos de período 2) como patrón patológico y termina de forma monótona con un hardcap de generaciones: traslada a umbrales matemáticos el “giro infinito” de este texto y la terminación monótona por MaxTries del loop de reins.
  • proof-loop — “El verificador debe ser una sesión nueva. El agente que hizo el cambio no dictamina si ya terminó.” Congela los criterios de aceptación antes de implementar, separa al constructor del verificador, y solo termina cuando todos los criterios reciben un PASS nuevo. Una separación de potestades que se enfrenta de cara a la “convergencia falsa” de este texto (el estudiante corrige su propio examen).
  • auto-re-agent — Enchufa al loop reverser/checker un objective verifier (verificación estructural de call-count y control-flow) y un motor de parity multiseñal (GREEN/YELLOW/RED). Ata los intentos con un número máximo de rondas para cortar la divergencia. La misma intuición que el gate de reins: el aprobado lo cierra una regla, no el juicio del LLM.

Y el linaje más amplio de este diagnóstico —episteme, MagLab, Manifesto, oh-my-kamisama— está recopilado en la sección “Para seguir leyendo” de reins. El mismo muro, la misma conclusión, también están allí en fila.

Fuentes

  • Osmani, A. (2026). “Loop Engineering.” addyosmani.com/blog (2026-06-07). Blog — El origen de la tendencia “no introduzcas prompts, diseña el loop”. La fuente original del “un loop que corre sin supervisión falla sin supervisión” citado en el cuerpo.
  • Hu, W. (2026). “From Agent Loops to Structured Graphs: A Scheduler-Theoretic Framework for LLM Agent Execution.” arXiv:2604.11378 — Señala los “unbounded recovery loops” (reintentos infinitos) como debilidad estructural del Agent Loop y propone garantías formales de terminación. Fundamento de la primera cara de la divergencia, el ‘giro infinito’, y de la terminación monótona.
  • Mohamed, A., Geng, M., Vazirgiannis, M., & Shang, G. (2025). “LLM as a Broken Telephone: Iterative Generation Distorts Information.” arXiv:2502.20258 — Cuanto más procesa el modelo de forma repetida su propia salida, más se acumula gradualmente la distorsión de información. Sostiene directamente la segunda cara de la divergencia, la ‘deriva’ (acumulación con interés compuesto del error).
  • Bondarenko, A. et al. (2025). “Demonstrating Specification Gaming in Reasoning Models.” arXiv:2502.13295 — Cuanto mayor es la capacidad del modelo de razonamiento, mejor encuentra las grietas de la verificación. Fundamento de la tercera cara de la divergencia, el ‘reward hacking’.
  • Helff, L. et al. (2026). “LLMs Gaming Verifiers: RLVR can Lead to Reward Hacking.” arXiv:2604.15149 — La frecuencia de shortcuts crece junto con la complejidad de la tarea y el cómputo de razonamiento. Fundamento cuantitativo de que, sobre una verificación floja, el reward hacking es proporcional a la capacidad.
  • Huang, J. et al. (2024). “Large Language Models Cannot Self-Correct Reasoning Yet.” ICLR 2024. arXiv:2310.01798 — La autocorrección sin feedback externo no mejora el rendimiento y más bien lo empeora. Fundamento central de “si dictaminas tu propio completado, terminas equivocado” (convergencia falsa).
  • Stechly, K., Valmeekam, K., & Kambhampati, S. (2024). “On the Self-Verification Limitations of Large Language Models.” arXiv:2402.08115 — La autoverificación apenas mejora el rendimiento. La razón por la que el dictamen PASS debe residir en un gate determinista.
  • Xu, W. et al. (2024). “Pride and Prejudice: LLM Amplifies Self-Bias in Self-Refinement.” arXiv:2402.11436 — Si evalúas tu propia salida, el self-bias se amplifica. Fundamento de que el acoplamiento generador=juez agranda la deriva, y justificación de separar la ranura de juicio.
  • Sharma, M. et al. (2023). “Towards Understanding Sycophancy in Language Models.” arXiv:2310.13548 — La adulación es una tendencia general de los modelos RLHF, y el juicio de preferencia humana la induce. Fundamento del valor por defecto de responder “Sí” a “¿ya está?”, y de la doble cara en la que la adulación se vuelve activo en el feedback de hechos.
  • Fanous, A. et al. (2025). “SycEval: Evaluating LLM Sycophancy.” AAAI/ACM AIES 2025. arXiv:2502.08177 — Medición de la tasa de capitulación adulatoria. Fundamento cuantitativo del mecanismo de convergencia “en los hechos la adulación es medicina”.
  • Von Neumann, J. (1956). “Probabilistic Logics and the Synthesis of Reliable Organisms from Unreliable Components.” Automata Studies, Princeton University Press. — El principio de montar un protocolo confiable (gate determinista) sobre componentes inestables (LLM probabilístico). La premisa de “la generación es probabilística, el aprobado es determinista”.