Qué es un agent loop (y qué no): estado, acción, parada

Un agent loop es el ciclo en el que un modelo de lenguaje decide una acción, esa acción se ejecuta, y el resultado vuelve a entrar como contexto para la siguiente decisión, hasta que se cumple una condición de parada. Esa repetición —decidir, actuar, observar, repetir— es lo que separa a un agente de un chat. Un chat responde una vez a cada mensaje; un agente corre ese ciclo solo, muchas veces, hasta terminar la tarea. Este es el primer post de una serie sobre cómo funcionan los agentes de IA por dentro, y empieza por la pieza que le da nombre a todo: el loop.

Resumen para perezosos

• Un agent loop tiene tres piezas: un estado (lo que el agente sabe hasta ahora), una acción (lo que hace en cada vuelta) y una condición de parada (cuándo decide que terminó).
• La diferencia con un chat no es el modelo, es quién corre el ciclo: en un chat lo corres tú —lees, ejecutas, vuelves a preguntar—; en un agente lo corre el programa.
• "Hazme una app" es un prompt para un chat y un objetivo para un agente. La misma frase, dos arquitecturas distintas.

En este artículo:

• Fundamentos — Qué es un agent loop · Los tres componentes
• El contraste — Chat o agente · Qué no es un agent loop
• La mecánica — El loop en pseudocódigo · El vocabulario de la serie

Qué es un agent loop

Un modelo de lenguaje, por sí solo, hace una cosa: recibe texto y produce texto. Una entrada, una inferencia, una salida. No ejecuta nada, no recuerda lo de antes, no comprueba si acertó. Cada llamada es independiente y termina en cuanto el modelo deja de escribir.

Un agente envuelve esa inferencia en un ciclo. La salida del modelo ya no es la respuesta final, sino una decisión: “ejecuta este comando”, “lee este archivo”, “busca esto”. El programa ejecuta esa decisión, captura el resultado, y se lo devuelve al modelo como nuevo contexto. Entonces el modelo decide otra vez, con más información que antes. Esa vuelta se repite hasta que la tarea está hecha.

La pieza nueva no es el modelo, es el ciclo a su alrededor. El mismo modelo que en un chat respondería una vez, dentro de un loop se llama diez o cincuenta veces, acumulando contexto en cada paso. Por eso un agente puede resolver tareas de varios pasos que un chat solo puede describir: no porque el modelo sea más capaz, sino porque su salida se realimenta en lugar de terminar.

Los tres componentes: estado, acción y condición de parada

Todo agent loop, por simple o complejo que sea, se reduce a tres piezas. Si entiendes estas tres, entiendes el patrón completo.

Estado. Es todo lo que el agente sabe en este punto: el objetivo, el historial de acciones que ya tomó y los resultados que obtuvo. El estado crece en cada vuelta, porque cada acción y su resultado se suman al contexto. La primera entrada del estado es el objetivo; la última, lo que acaba de observar.

Acción. Es lo que el agente hace en cada iteración. Casi siempre es llamar a una herramienta: ejecutar un comando, leer o escribir un archivo, hacer una búsqueda, llamar a una API. Un detalle que importa y que la serie va a repetir: el modelo no ejecuta nada. El modelo elige la acción; el programa la ejecuta. Esa separación es lo que hace al loop seguro y depurable.

Condición de parada. Es la regla que corta el ciclo. Puede ser que el modelo emita una acción de “terminé”, que se cumpla un objetivo verificable (los tests pasan, el archivo existe) o un tope de iteraciones como red de seguridad. Sin una condición de parada clara, un agente no termina o no sabe que ya terminó.

La forma más rápida de fijar estos roles es ver quién maneja cada uno:

Componente	Qué es	Quién lo maneja
Estado	El objetivo más el historial de acciones y resultados	El programa lo acumula
Acción	La decisión de qué hacer en esta vuelta	El modelo la elige, el programa la ejecuta
Condición de parada	La regla que decide cuándo cortar	El programa la comprueba

El reparto de la última columna es el centro del patrón: el modelo aporta el juicio (qué hacer ahora), y el programa aporta la ejecución y el control (hacerlo y decidir cuándo parar). Confundir esos dos roles es la causa de la mayoría de los agentes que se comportan mal.

Chat o agente: por qué “hazme una app” cambia de significado

La forma más clara de ver la diferencia es tomar una sola frase —“hazme una app”— y meterla en los dos sistemas.

En un chat, “hazme una app” es un prompt. El modelo produce un bloque de código y ahí termina su trabajo. Si el código no compila, el que corre el ciclo eres tú: lees el error, lo pegas de vuelta, pides un arreglo, lo vuelves a ejecutar. El chat hace una inferencia por mensaje; el loop —probar, observar, corregir— lo pones tú, a mano, desde fuera.

En un agente, “hazme una app” es un objetivo. El agente escribe el código, lo ejecuta él mismo, lee el error que sale, lo corrige y vuelve a ejecutar, hasta que los tests pasan o se rinde. El loop está dentro del programa. Tú diste el objetivo una vez; el ciclo de probar y corregir corre solo.

CHAT                                AGENTE

"hazme una app"                     "hazme una app"  (objetivo)
      │                                   │
      ▼                                   ▼
   modelo                          ┌──► modelo ──► acción ──► resultado ─┐
      │                            │                                     │
      ▼                            └──────────── estado ◄────────────────┘
   salida                                         │
      │                                   ¿condición de parada?
   (paras tú,                                     │
    corres el loop                         sí ──► entregar
    a mano)

La misma frase, dos arquitecturas. Y la diferencia no es la inteligencia del modelo ni el tamaño del prompt: es dónde corre el loop. En el chat lo corres tú, paso a paso; en el agente lo corre el código. Ese desplazamiento —del humano al programa— es todo lo que significa “agente”.

Qué no es un agent loop

El título promete decir también qué no es un agent loop, porque ahí es donde se acumula la confusión. Tres cosas se confunden con un agente y no lo son:

• Un solo turno de chat, aunque use herramientas. Una llamada con tool calling que ejecuta una función y responde una vez no es un loop; es una inferencia con un paso extra. Se vuelve loop solo cuando el resultado de la herramienta vuelve a entrar al modelo y este decide otra acción. Una vuelta no es un ciclo.
• Una cadena fija de prompts. Si la secuencia de pasos la escribiste tú y siempre es la misma —primero resume, luego traduce, luego clasifica—, eso es un workflow determinista, no un agente. Una pipeline de automatización con n8n es justo eso: el orden ya está decidido antes de ejecutar. Un agente decide la siguiente acción en tiempo de ejecución, no antes.
• Un script con un LLM en un bucle. Llamar al modelo dentro de un for no lo convierte en agente si el modelo no elige las acciones ni cuándo parar. La autonomía no está en que haya repetición, está en que la decisión sea del modelo en cada vuelta.

La pregunta que de verdad clasifica un sistema no es “¿usa un LLM?”, sino “¿quién decide el siguiente paso?”. Si la respuesta eres tú, o un diagrama fijo que dibujaste de antemano, es un workflow. Si la respuesta es el modelo, vuelta a vuelta, es un agente.

Esta distinción no es purismo de vocabulario. Un workflow y un agente se construyen, se prueban y se depuran de formas distintas. Llamar agente a un workflow lleva a meterle autonomía que no necesita; llamar workflow a un agente lleva a no ponerle las barreras que sí necesita.

El loop en pseudocódigo

Quitado todo lo accesorio, un agent loop es un while. Esta es la forma mínima, con los tres componentes señalados:

# El agent loop, sin adornos.

estado = contexto_inicial(objetivo)        # el objetivo es la primera entrada al estado

while not terminado(estado):               # ← condición de parada
    accion    = modelo.decidir(estado)     # ← el modelo ELIGE la acción
    resultado = ejecutar(accion)           # ← el programa la EJECUTA (tool, comando, API)
    estado    = estado + accion + resultado # la observación se realimenta al estado

return estado

Cuatro líneas dentro del while y ahí está todo: el estado entra, el modelo decide, el programa ejecuta, el resultado vuelve al estado. Cada iteración es un turno del agente. Lo único que cambia entre un agente de juguete y uno de producción es qué herramientas puede llamar ejecutar, qué tan bien se gestiona el estado cuando crece, y qué tan robusta es la condición de parada.

Esa condición de parada casi nunca es una sola cosa. En la práctica combina la decisión del modelo con un tope rígido, para que el ciclo nunca sea infinito:

def terminado(estado):
    if estado.ultima_accion == "finalizar":   # el modelo decidió que ya está
        return True
    if estado.iteraciones >= MAX_ITER:         # red de seguridad: nunca un loop sin fin
        return True
    return False

La primera condición es autonomía: el modelo señala que cumplió el objetivo. La segunda es control: pase lo que pase, el loop para. Un agente bien hecho tiene siempre las dos. Solo la primera y un error del modelo te deja un proceso girando para siempre; solo la segunda y el agente se corta a la mitad de tareas que aún no había terminado.

En producción ese tope rígido rara vez es un solo contador de iteraciones. Suele incluir también un límite de tiempo, un presupuesto de tokens o de costo, detección de ciclos —el modelo repitiendo la misma acción sin avanzar— y, para acciones peligrosas, una aprobación humana antes de ejecutar. Todo eso es la misma idea: el control vive fuera del modelo, en el programa que lo envuelve. Es, probablemente, la parte del diseño que más se descuida y la que más caro se paga cuando falta.

Una aclaración honesta sobre ese while: es el modelo mental correcto, pero no siempre la implementación literal. En sistemas reales el loop suele tomar la forma de una máquina de estados, un grafo (como en LangGraph) o un flujo dirigido por eventos, y el razonamiento de cada vuelta puede seguir patrones con nombre propio —ReAct, plan-y-ejecuta, reflexión— que reordenan los pasos. Por debajo de todos sigue estando el mismo ciclo: decidir, actuar, observar, repetir. El while es la esencia; el resto es cómo se organiza esa esencia cuando la tarea crece y el loop deja de ser una sola pieza para volverse parte de una arquitectura más grande.

El vocabulario que usaremos en la serie

Este post fija los términos que el resto de la serie va a dar por sabidos. Conviene dejarlos claros de una vez:

• Estado (o contexto): todo lo que el agente sabe en un momento dado. El objetivo más el historial de acciones y observaciones.
• Acción: la decisión del modelo en una vuelta. Normalmente, llamar a una herramienta (tool).
• Observación: el resultado de ejecutar una acción, que se devuelve al estado.
• Iteración (o turno): una vuelta completa del loop: decidir, actuar, observar.
• Condición de parada: la regla que termina el ciclo, casi siempre una mezcla de “el modelo dice que terminó” y “se alcanzó el tope”.
• Autonomía: que el modelo decida la acción y el final, no el código que lo rodea.

Con estos seis términos se puede describir cualquier agente, por sofisticado que sea. Los siguientes posts de la serie entran en cada pieza por separado: cómo se diseñan las herramientas, cómo se maneja el estado cuando el contexto se llena, y cómo se afinan las condiciones de parada para que el agente ni se corte antes de tiempo ni se quede dando vueltas.

Preguntas frecuentes

¿Un chatbot con herramientas ya es un agente?

No por el solo hecho de tener herramientas. Si el modelo llama a una función, recibe el resultado y responde una vez, eso es una inferencia con un paso extra, no un loop. Se vuelve un agente cuando el resultado de la herramienta vuelve a entrar al modelo y este decide la siguiente acción, repitiendo el ciclo hasta una condición de parada. La frontera es la realimentación, no la presencia de herramientas.

¿Cuál es la diferencia entre un agente y un workflow de prompts?

Quién decide el orden de los pasos. En un workflow la secuencia la escribiste tú y es fija: siempre los mismos pasos en el mismo orden. En un agente la siguiente acción la decide el modelo en tiempo de ejecución, según lo que observó hasta ese punto. Un workflow es predecible y fácil de depurar; un agente es flexible pero hay que ponerle barreras. Muchos problemas reales se resuelven mejor con un workflow, y conviene no convertir en agente lo que no lo necesita.

¿Qué pasa si el agente nunca decide parar?

Por eso la condición de parada casi nunca es solo “el modelo dice que terminó”. Se le añade un tope rígido de iteraciones (o de tiempo, o de costo) que corta el loop pase lo que pase. Si dependes únicamente de que el modelo decida parar, un solo error de juicio deja el proceso girando y gastando tokens sin avanzar.

¿Necesito un framework para construir un agent loop?

No. El núcleo es un while con tres piezas: estado, acción y condición de parada. Lo puedes escribir a mano en cualquier lenguaje. Los frameworks aportan utilidades —gestión de herramientas, manejo de memoria, trazas— que ayudan cuando el agente crece, pero ninguno es necesario para entender ni para arrancar. Empezar sin framework suele ser la mejor forma de entender qué hace cada uno por dentro.

¿El modelo “decide” de verdad o sigue reglas?

Decide en el sentido operativo: dado el estado actual, el modelo produce la siguiente acción, y esa elección no estaba escrita de antemano en el código. No es voluntad ni razonamiento humano, pero tampoco es una tabla de reglas fija: es la diferencia entre un programa donde el camino está cableado y uno donde el camino lo elige el modelo en cada vuelta. Esa elección en tiempo de ejecución es justo lo que distingue a un agente de un workflow.

Conclusión

Un agent loop no tiene nada de mágico: es un ciclo while con tres componentes —estado, acción y condición de parada— alrededor de un modelo que, en lugar de responder una vez, decide la siguiente acción una y otra vez hasta terminar. La prueba para saber si algo es un agente no es si usa un LLM, sino quién decide el siguiente paso; si la respuesta es el modelo, vuelta a vuelta, es un agente. Con ese vocabulario fijado —estado, acción, observación, iteración, condición de parada, autonomía— la serie puede entrar en cada pieza por separado. El siguiente post abre el componente “acción”: cómo se diseñan las herramientas que un agente puede llamar.