Anatomía de un agentic loop: Plan-Execute-Verify

Cuando la gente habla de “agentes de IA” suele imaginar algo mágico: un modelo que, de algún modo, hace cosas por su cuenta. La realidad es más mundana y más interesante. En el corazón de todo agente hay un bucle. Un ciclo que se repite: el modelo decide qué hacer, algo lo ejecuta, se comprueba el resultado, y se vuelve a empezar hasta que la tarea está terminada o se agota algún límite.

Ese bucle —el agentic loop— es donde vive la ingeniería de verdad. No en el modelo, que es una pieza intercambiable, sino en cómo se estructura el ciclo que lo rodea. Este artículo desmonta el bucle pieza por pieza: el patrón Plan-Execute-Verify, los presupuestos que impiden que se descontrole, las condiciones de parada y los disparadores de compactación. Es el artículo más técnico de la serie hasta ahora, y el que más te acerca a cómo funcionan estas cosas por dentro.

El patrón Plan-Execute-Verify#

El bucle más robusto que se ha impuesto en producción sigue tres fases que se repiten: planificar, ejecutar, verificar.

En la fase de planificación, el modelo recibe el estado actual de la tarea y decide cuál es el siguiente paso. No resuelve todo de golpe; decide la siguiente acción. Puede ser llamar a una herramienta, pedir información o concluir que la tarea está completa.

En la fase de ejecución, el harness toma la acción que el modelo ha propuesto y la lleva a cabo. Aquí es crucial el principio que ya vimos: el modelo no ejecuta nada directamente. Propone una llamada estructurada a una herramienta; el harness valida el esquema, comprueba los permisos, ejecuta la acción y captura el resultado.

En la fase de verificación, se comprueba qué ha pasado. ¿La acción tuvo éxito? ¿El resultado acerca la tarea a su objetivo? ¿Ha surgido un error que hay que manejar? El resultado de esta verificación se inyecta de vuelta en el contexto, y el bucle vuelve a empezar con un estado actualizado.

Este ciclo acotado —planificar un paso, ejecutarlo de forma mediada, verificar el resultado— es lo que convierte un modelo que genera texto en un agente que progresa hacia un objetivo. La diferencia con un simple “pídele al modelo que haga la tarea entera” es enorme: el bucle permite corregir el rumbo en cada iteración, en lugar de comprometerse con un plan completo que puede estar equivocado desde el principio.

Un esbozo en pseudocódigo del bucle, despojado de detalles, se ve así:

estado = inicializar(tarea)
presupuesto = Presupuesto(tokens=..., llamadas=..., tiempo=...)

mientras no condicion_de_parada(estado, presupuesto):
    accion = modelo.planificar(contexto(estado))

    si accion.tipo == "finalizar":
        romper

    resultado = harness.ejecutar(accion)   # valida, autoriza, ejecuta
    estado = verificar_e_integrar(estado, resultado)

    si contexto_saturado(estado):
        estado = compactar(estado)

    presupuesto.descontar(accion, resultado)

devolver estado.resultado_final

La aparente simplicidad engaña. Cada una de esas líneas esconde decisiones de diseño que determinan si el agente funciona o se descontrola.

Los presupuestos: por qué un agente necesita límites#

Un modelo sin límites en un bucle es una receta para el desastre. Sin restricciones, un agente puede entrar en bucles infinitos, consumir cantidades ruinosas de tokens o quedarse atascado repitiendo la misma acción fallida. Por eso todo bucle serio incorpora presupuestos.

Un presupuesto es un conjunto de límites que el bucle respeta. El más obvio es el presupuesto de tokens: cuántos tokens totales puede consumir la tarea antes de detenerse. Los tokens cuestan dinero, así que este límite es también un control de costes directo. Está el presupuesto de llamadas: cuántas acciones o iteraciones puede realizar el agente. Y el presupuesto de tiempo: cuánto puede tardar una tarea antes de abortarse. Cuánto cuesta de verdad cada uno de esos tokens, y por qué la factura rara vez coincide con la tabla de precios, lo desglosamos en qué pagas de verdad en tokens.

Estos límites no son solo protección contra costes. Son también una salvaguarda de fiabilidad. Un agente que ha consumido su presupuesto sin completar la tarea te está diciendo algo útil: que la tarea es más difícil de lo previsto, o que está atascado. Es mucho mejor que se detenga y lo reporte a que siga quemando recursos indefinidamente. El presupuesto convierte un fallo silencioso y caro en un fallo visible y acotado.

Las condiciones de parada#

Íntimamente ligadas a los presupuestos están las condiciones de parada: las reglas que determinan cuándo el bucle debe terminar. Diseñarlas bien es más sutil de lo que parece.

La condición de parada deseable es que la tarea se complete: el modelo determina que ha alcanzado el objetivo y emite una acción de finalización. Pero hay condiciones de parada defensivas que también hay que contemplar. Que se agote cualquiera de los presupuestos. Que el agente repita la misma acción fallida un número de veces (señal de que está atascado). Que surja un error irrecuperable. Que una acción de alto riesgo requiera aprobación humana y esta no llegue.

El equilibrio delicado está entre parar demasiado pronto y parar demasiado tarde. Un bucle que se rinde al primer obstáculo no aprovecha la capacidad del modelo de corregir el rumbo. Uno que nunca se rinde puede quemar recursos en tareas imposibles. Ajustar estas condiciones para cada tipo de tarea es parte del oficio del harness engineering, la disciplina que enmarca todo esto y que abrimos en el andamiaje que rodea al modelo.

La compactación: cuando el contexto se llena#

Hay un problema que aparece en cuanto las tareas se alargan: la ventana de contexto se llena. Cada iteración del bucle añade información —la acción tomada, el resultado obtenido, la verificación— y ese historial crece. En tareas largas, puede superar lo que cabe en la ventana del modelo.

La solución es la compactación: comprimir el historial para que quepa, conservando lo esencial y descartando lo prescindible. Un disparador de compactación es una condición que, cuando se cumple (por ejemplo, cuando el contexto alcanza cierto porcentaje de la ventana), activa un proceso que resume o poda el estado acumulado.

La compactación es un tema lo bastante rico como para merecer su propio artículo, y lo tiene: cómo se compacta la ventana de contexto. Por ahora basta con entender su papel en el bucle: es lo que permite que un agente sostenga tareas que abarcan muchas iteraciones sin ahogarse en su propio historial. Sin compactación, el horizonte de un agente está limitado por el tamaño de su ventana de contexto. Con ella, puede abordar tareas mucho más largas.

Un ejemplo del mundo real#

Vale la pena aterrizar todo esto en un caso concreto. El agente de SRE que Microsoft construyó para Azure implementa exactamente este tipo de bucle acotado. Cuando ocurre un incidente, el agente planifica un paso de investigación, lo ejecuta a través de herramientas mediadas (leer logs, consultar métricas, revisar código), verifica lo que ha encontrado e integra ese hallazgo en su estado. Repite el ciclo hasta que identifica la causa y propone una mitigación. Esas herramientas mediadas son hoy, en la mayoría de casos, servidores que hablan un protocolo común: qué es el Model Context Protocol y por qué se impuso.

Lo notable es que este bucle, correctamente diseñado, ha gestionado más de 35.000 incidentes de forma autónoma, reduciendo el tiempo de mitigación de más de 40 horas a 3 minutos en ciertos casos. Y para acciones de alto riesgo, el bucle incorpora una condición de parada específica: se detiene y espera aprobación humana antes de proceder. Es el patrón Plan-Execute-Verify con presupuestos, condiciones de parada y gobernanza, funcionando a escala de producción.

Lo que hay que retener#

El bucle es la unidad fundamental de un agente. Entender su anatomía —las tres fases, los presupuestos que lo acotan, las condiciones que lo detienen, la compactación que lo sostiene— es entender cómo funciona un agente por dentro, más allá de la magia aparente.

Y hay una lección de diseño que trasciende los detalles: un buen agente no es el que tiene el mejor modelo, sino el que tiene el bucle mejor diseñado. Los presupuestos que impiden el descontrol, las condiciones de parada que distinguen “atascado” de “en progreso”, la mediación que hace segura cada acción: ahí es donde un equipo demuestra su oficio. El modelo lo pones desde una API. El bucle lo construyes tú, y es lo que separa un agente que funciona en producción de uno que solo impresiona en una demo.