(1/3) Solo dos cosas hacen que un loop sea agéntico

«Agéntico» se ha convertido en la palabra más sobrecargada del software, y casi nadie que la use sabe decirte qué dos cosas hacen que un loop lo sea de verdad.

Programo desde finales de los noventa, y la mayor parte de ese tiempo lo he pasado manteniendo sistemas que despiertan a alguien a las 3 de la madrugada cuando se portan mal. Así que cuando algo se ejecuta solo, en loop, decidiendo qué hacer a continuación sin que yo escriba nada entre medias, la primera pregunta nunca es «¿es lo bastante inteligente?». Es «¿cuándo se detiene, y cómo sé que se ha detenido por el motivo correcto?».

Esa pregunta acaba ordenando todo el campo. El marketing mezcla dos cosas muy distintas: una interfaz de chat que responde con educación, y un sistema que sigue actuando después de que hayas dejado de mirar. Solo la segunda es un loop, y lo que lo hace agéntico no son las buenas formas ni un avatar simpático: son dos piezas de ingeniería. Un trigger que lo pone en marcha sin que una persona escriba un prompt nuevo cada vez. Y un objetivo que alguien distinto del modelo pueda verificar, para que el loop tenga un motivo real para detenerse, en lugar de la opinión de un modelo que dice haber terminado.

Un loop necesita un trigger, no una ventana de chat

Una interfaz de chat es petición-respuesta: preguntas, responde, espera. Un loop agéntico arranca de otra cosa: un evento (llega un ticket, se dispara un webhook), una programación (cada noche a las 2), o una persona que le pasa una tarea y se va (arregla este test que está fallando). La diferencia importa porque cambia quién está pendiente. En una ventana de chat, lees cada respuesta antes de que ocurra la siguiente. En un loop, por diseño, nadie lo hace: ese es precisamente el motivo de construir uno. Lo que significa que el loop tiene que llevar su propio criterio sobre si ha terminado, porque tú no estás ahí para dárselo turno a turno.

Los tres tipos de trigger, además, no son intercambiables. Uno basado en eventos hereda los problemas de fiabilidad de la cola o el webhook que lo alimenta: eventos duplicados, entregas fuera de orden, un reintento que dispara el mismo loop dos veces con la misma entrada. Uno programado hereda el problema contrario: se ejecuta haya trabajo o no, así que el primer paso dentro del loop suele tener que ser «¿hay realmente algo que hacer aquí?», o has construido un no-operation caro que corre cada noche para siempre. El traspaso humano es el caso más indulgente, porque una persona ha elegido el momento, pero también es el que la mayoría de demos usan por defecto, lo que oculta cuánta responsabilidad de trigger cargan en realidad los otros dos tipos.

El objetivo lo tiene que poder verificar alguien distinto del modelo que ha hecho el trabajo

Esta es la pieza que la mayoría de demos «agénticas» se saltan. Si la única prueba de que una tarea ha funcionado es el propio modelo diciendo «hecho», no tienes una condición de parada: tienes la opinión de un modelo, y los modelos se equivocan a menudo sobre su propio trabajo, justo de las maneras que cabría esperar: pasan por alto casos límite, marcan como verde un build roto, dan por terminada una migración a medias. Un objetivo verificable lo comprueba algo externo al razonamiento que lo ha producido: un test que pasa o falla, un esquema que valida, un diff que revisa una persona o un segundo modelo. Donde falta esa comprobación, el loop no tiene un objetivo. Tiene una sensación con un botón de parada que nadie está obligado a pulsar.

Percibir, razonar, planificar, actuar, observar: la forma que hay debajo de todos estos sistemas

Una vez tienes un trigger y un objetivo verificable, el loop en sí sigue una forma fija: percibir el estado actual (leer el archivo, el error, el ticket), razonar sobre qué implica, planificar el siguiente paso, actuar, observar el resultado, y repetir hasta que la comprobación del objetivo pase o se toque un límite. Lo nuevo no es la construcción del loop: llevamos décadas escribiendo while (!hecho). Lo nuevo es que el modelo razona sobre estado no estructurado entre acciones, en lugar de seguir un guion fijo escrito de antemano.

Ese movimiento concreto —intercalar un rastro de razonamiento con cada acción, en vez de comprometerse con un plan de antemano y ejecutarlo a ciegas— es lo que formalizó ReAct. El artículo de Yao et al. de 2022 (publicado en ICLR 2023) mostró que dejar que un modelo genere un rastro de razonamiento breve antes de cada acción, en vez de actuar directamente desde el prompt, producía una mejora absoluta en la tasa de éxito del 34% en ALFWorld y del 10% en WebShop frente a métodos previos de imitación y de refuerzo, usando solo uno o dos ejemplos en el prompt. El mecanismo es lo que cuenta: el rastro de razonamiento deja que el modelo se dé cuenta, a mitad de tarea, de que su última acción no ha hecho lo que esperaba, y corrija el rumbo, en vez de comprometerse con un plan estático y ejecutarlo hasta el fracaso.

El paso de observar es el que la mayoría de implementaciones tempranas se quedan cortas. Es tentador tratar «actuar» como el final del ciclo y alimentar el siguiente razonamiento con lo que haya devuelto la acción, sin filtrar. Pero una llamada a una herramienta puede fallar en silencio: un script que devuelve 0 sin haber hecho nada, una API que devuelve una lista vacía en vez de un error. Si el loop no comprueba explícitamente qué ha pasado de verdad frente a lo que esperaba que pasara, razonará hacia delante desde una premisa falsa. Buena parte de lo que parece «el modelo es corto» en un loop que se porta mal es esto: nadie ha construido un paso de observación real, así que el loop razona sobre una imagen del mundo vieja o incorrecta.

Ya hemos visto esta película: la viralidad no es un objetivo verificable

AutoGPT se lanzó en marzo de 2023 y se convirtió en uno de los repositorios de crecimiento más rápido en la historia de GitHub, con cifras que apuntan a más de 100.000 estrellas en pocas semanas. También se convirtió en el ejemplo de advertencia más claro del campo, por un motivo que encaja exactamente con los dos requisitos anteriores: tenía triggers y tenía ambición, pero no tenía de forma fiable un objetivo que algo fuera del modelo pudiera comprobar. Usuarios reportaron loops indefinidos, presupuesto de API quemado persiguiendo una tarea que ya había terminado en la práctica, o desvíos completos del encargo original. El diagnóstico de Andrej Karpathy sobre agentes construidos así fue directo: una ventana de contexto finita los lleva a «salirse de los raíles». Avram Piltch, de Tom's Hardware, lo dijo más afilado en su reseña de abril de 2023: AutoGPT podía ser «demasiado autónomo para ser útil». La distancia entre AutoGPT y ReAct es reveladora: uno era una demo viral con trigger y sin parada verificable; el otro era un artículo aburrido y medido con benchmarks que había resuelto el problema de ingeniería real seis meses antes, con una fracción de la atención.

Sí, mecánicamente, es un while loop

Concedo la objeción obvia, porque es cierta hasta donde llega: quita la terminología y un loop agéntico es un while alrededor de una llamada a un modelo. No hay magia escondida en el flujo de control. Lo que cambia es quién calcula la condición y el siguiente paso. En un programa normal, los habías escrito tú de antemano. Aquí, un modelo lee estado no estructurado —logs, un diff, un archivo a medio escribir, un mensaje de error— y decide tanto qué hacer a continuación como, si lo has construido bien, si ya ha terminado. Eso es un salto de capacidad real. Y es exactamente por eso que el requisito de verificación de antes no es opcional: la misma flexibilidad que le permite al modelo manejar un caso que no habías previsto es la que le permite convencerse de que algo roto está bien.

Antes de llamar loop a algo, compruebo cuatro cosas

1. Qué lo pone en marcha, dicho de forma explícita —evento, programación o traspaso humano. Si nadie sabe nombrar el trigger, alguien está planeando hacer de niñera de un script improvisado.
2. Un objetivo definido como una comprobación externa, no como una pregunta que le harías al modelo sobre su propio trabajo. Un test, un validador, un diff que revisa otra persona.
3. Una parada dura independiente del modelo —un número máximo de iteraciones o un límite de presupuesto que salta aunque el modelo insista en que está a punto de terminar. Es lo que le faltaba a AutoGPT.
4. Un rastro visible de qué ha hecho y por qué, en cada paso, para que un fallo sea una sesión de depuración y no un misterio.

La pregunta de arquitectura viene ahora

Nada de esto te dice cuántos modelos deberían hacer el razonamiento, ni si deberían correr en paralelo, en secuencia, o con un supervisor leyendo su trabajo. Esa es una decisión aparte, con su propia curva de coste, y es el tema de la segunda parte de esta serie. Pero empieza aquí: un trigger, y un objetivo que alguien distinto del modelo pueda comprobar. Todo lo que la gente llama «agéntico» y se salta uno de los dos es una demo, no un sistema que quisieras dejar corriendo sin supervisión.

Si estás construyendo uno de estos sistemas y quieres hablar de cómo encaja en un stack de producción, contáctanos.