(3/3) El loop nunca fue la parte difícil — los guardrails sí lo son
Hacer que un modelo perciba, razone, planifique, actúe y observe en ciclo ya es fácil hoy en día. Cualquier framework te da ese loop en cuatro líneas. La parte difícil —la que ningún framework hace por ti— es todo lo que evita que el loop se coma tu dinero, tus datos de producción, o las dos cosas, sin hacer ruido.
En la primera parte decía que el fallo real de AutoGPT, en marzo de 2023, no fue un modelo débil: fue la condición de parada que le faltaba, y el sector ha reaprendido esa lección a trozos desde entonces, una factura de API descontrolada cada vez. Tres años después, la mecánica del loop es un problema resuelto, publicado y medido con benchmarks. Lo que separa una demo de algo que dejarías tocar producción no es un modelo más inteligente dentro del loop: es la disciplina que lo rodea. Llamemos a eso loop engineering: es una lista corta y concreta de guardrails, y la mayoría de incidentes se remontan a que se saltó uno de ellos.
Un límite de iteraciones que salta pase lo que pase diga el modelo
El primer guardrail es el más básico y el que más falta: un máximo duro de cuántos ciclos puede correr un loop, impuesto desde fuera del modelo, que salta aunque la salida del propio modelo insista en que le queda un paso para terminar. Suena demasiado obvio para escribirlo hasta que recuerdas que AutoGPT se lanzó sin eso: la herramienta que convirtió «agéntico» en una palabra de uso corriente en ingeniería no tenía un techo duro sobre su propio loop, y usuarios lo encontraban con regularidad todavía corriendo, y todavía facturando, mucho más allá del punto en que la tarea tenía alguna posibilidad de salir bien. Un modelo al que le preguntas «¿ya has terminado?» a menudo dirá que no cuando debería decir que sí, y que sí cuando debería decir que no; un límite que no le pide su opinión es la solución.
Un techo de presupuesto, porque los tokens son la unidad que se acaba
La segunda parte explicaba por qué la arquitectura es una curva de coste: un sistema multi-agente puede correr a unas 15 veces los tokens de una simple interacción de chat, según las cifras que la propia Anthropic ha publicado sobre su sistema de investigación. Un loop construido sin un techo de presupuesto explícito no falla haciendo ruido cuando llega a ese múltiplo; falla como una factura, días después, cuando alguien la lee. La solución es aburrida e innegociable: un techo de tokens o de dinero impuesto en la capa de infraestructura, independiente de la propia contabilidad del loop, porque un loop que ya se está portando mal es el último al que querrías hacer responsable de vigilar su propio gasto.
Detección para el fallo que parece que no pasa nada
Los límites de iteraciones y los techos de presupuesto atrapan un loop que hace demasiado. Un fallo más silencioso es un loop que no hace nada nuevo: repitiendo el mismo movimiento improductivo, releyendo el mismo archivo, reintentando la misma llamada que falla, sin avanzar de forma medible hacia el objetivo. Este caso necesita su propia comprobación: compara el estado entre iteraciones, y si nada cambia de forma significativa durante N ciclos seguidos, detente y márcalo en vez de dejar que el límite lo atrape eventualmente después de haber quemado todo el presupuesto en un loop que ya estaba atascado tres iteraciones antes.
El «context rot» ya es un fallo de producción con nombre e informe propios
Hay una segunda versión, más sutil, de «atascado»: un loop que sigue produciendo salida nueva en cada ciclo, pero la salida empeora a medida que crece la transcripción, porque el contexto acumulado del propio modelo degrada su razonamiento. El informe de Chroma Research de julio de 2025, «Context Rot: How Increasing Input Tokens Impacts LLM Performance» (Hong, Troynikov y Huber), evaluó dieciocho modelos de primera línea y encontró que la precisión se degradaba de forma no uniforme a medida que crecía la longitud de entrada —mucho antes de llegar al límite de contexto declarado de un modelo—, con un hallazgo concreto y contraintuitivo: los modelos rendían peor con documentos largos lógicamente coherentes que con la misma longitud de texto mezclado e incoherente. Un loop de larga duración va añadiendo contenido a su propia transcripción por construcción, lo que significa que cada ciclo extra grava, sin que nadie lo note, exactamente el recurso que el informe muestra que se degrada. Un loop que nunca recorta ni reinicia su contexto se va gastando su propia calidad de razonamiento, ciclo a ciclo, alguien lo esté vigilando o no.
Vale la pena nombrar una respuesta deliberadamente brusca a este problema porque invierte el instinto de guardar más contexto, no menos: la técnica «Ralph Wiggum» de Geoffrey Huntley (ghuntley.com, mayo de 2025) hace correr un agente de código en un loop de bash contra un archivo de tarea persistente, pero reinicia la ventana de contexto del modelo en cada iteración: nada pasa de una transcripción a la siguiente. El estado sobrevive en el sistema de archivos y en el historial de git, fuera del modelo por completo. Es una respuesta a base de fuerza bruta al context rot: si una transcripción larga es lo que te degrada el razonamiento en silencio, no guardes ninguna larga; guarda el estado duradero en algún sitio que no se degrade, y deja que el modelo empiece cada ciclo de cero.
Orientarse, no solo observar, antes del siguiente paso
El ciclo percibir-razonar-planificar-actuar-observar de la primera parte tiene un primo más antiguo que merece la pena tomar prestado: el loop OODA de John Boyd —Observar, Orientar, Decidir, Actuar—, que desarrolló a lo largo de los años setenta y formalizó en sesiones como «Patterns of Conflict» en los ochenta, pensado originalmente para explicar por qué un piloto de caza podía decidir más rápido que otro en combate. El detalle que la mayoría de adaptaciones de OODA al software dejan fuera es el paso de orientar, distinto de simplemente observar: es el acto explícito de contrastar una observación nueva con el modelo que ya tienes de la situación, antes de decidir qué significa. Un loop agéntico que salta directamente de «observar la salida de la herramienta» a «decidir la siguiente acción» se salta exactamente este paso, y suele ser donde falla el loop que describía en la primera parte: el que razona hacia delante desde una imagen del mundo vieja o incorrecta. Orientarse es el guardrail que atrapa una mala observación antes de que se convierta en una decisión peor, no después.
Un punto de control antes de cualquier cosa irreversible, que un humano tenga que superar de verdad
Cada guardrail anterior trata de mantener acotado el comportamiento del propio loop. Este último trata de lo que el loop puede hacerle al mundo sin preguntar antes. Borrar datos, enviar un correo, hacer push a una rama compartida, gastar dinero real fuera de un presupuesto aislado: acciones como estas necesitan un punto de control humano explícito que el loop no pueda esquivar, no un flag de configuración que pueda razonar para superar si decide que la situación lo justifica. Los demás guardrails acotan cuánto tiempo y cuánto gasta un loop; este acota qué le está permitido hacer mientras corre, y es el que convierte un loop descontrolado en un error caro en vez de en uno irrecuperable, si falta.
Sí, cada uno de estos guardrails te cuesta velocidad
La objeción honesta a los seis es que frenan el loop: un límite de iteraciones significa que se detiene antes de que quizá hubiera terminado por sí solo, un punto de control humano significa una pausa real en vez de ejecución sin supervisión, un paso de orientarse significa un paso extra antes de cada decisión en vez de ir directo a la siguiente acción. Es cierto, y no es un defecto que optimizar cuando confíes más en el sistema. Todo el valor de un loop sin supervisión es que nadie lo vigila convirtiendo tokens en acciones en tiempo real; todo el riesgo es exactamente el mismo. Cada guardrail de aquí intercambia una parte de esa velocidad sin supervisión por la capacidad de dejarlo correr sin mirar cada ciclo, que es el punto real de construir un loop, no un impuesto que le pones.
Lo que pondría en marcha antes de dejar correr cualquier loop
- Un límite duro de iteraciones, impuesto desde fuera del modelo, que salta pase lo que pase diga su propia salida.
- Un techo de presupuesto —tokens o dinero— impuesto en la capa de infraestructura, no dentro de la contabilidad del propio loop.
- Detección de no-progreso que compara el estado entre ciclos y marca un atasco antes de que el límite lo atrape eventualmente.
- Una estrategia de contexto —recortar, resumir, o reiniciar como hace Ralph— para que la calidad del razonamiento no se degrade en silencio a medida que crece la transcripción.
- Un paso de orientarse explícito que contrasta cada observación nueva con el modelo que el loop ya tiene de la situación antes de decidir la siguiente acción.
- Un punto de control humano para cualquier cosa irreversible, que el loop no pueda esquivar razonando.
El loop es el 20% fácil; esto es el otro 80%
Ninguno de estos seis guardrails necesita un modelo más inteligente. Necesitan la misma disciplina que ha mantenido vivos los sistemas de producción desde mucho antes de que «agéntico» fuera una palabra que usara nadie: saber cuándo parar, saber qué cuesta algo, notar cuándo se atasca, y no dejarlo nunca hacer algo que no puedas deshacer sin preguntar antes. Ese es el hilo que atraviesa toda la serie: un trigger y un objetivo verificable en la primera parte, una arquitectura elegida por la forma real de la tarea en la segunda, y los guardrails de aquí que hacen que todo esto sea seguro de dejar correr. Acierta las tres, y un loop se gana su sitio sin que tengas que vigilarlo. Sáltate una, y tienes el problema de AutoGPT con un modelo mejor pegado encima.
Si estás construyendo uno de estos sistemas y quieres una segunda opinión sobre dónde deberían ir los guardrails, contáctanos.
