Ingeniería de bucles para agentes de IA: cinco partes, cuatro formas y una implementación en LangGraph.

Cada agente de IA ya funciona en un bucle, y casi nadie diseña ese bucle intencionadamente. Esa diferencia separa a un agente que termina silenciosamente la tarea de uno que agota el presupuesto en una sola noche, convencido de que está avanzando. La práctica para cerrar esa brecha tiene un nombre: ingeniería de bucles.

Estructuralmente es algo sencillo. En cada paso, el agente piensa en qué hacer, realiza una acción como una llamada a una herramienta o una búsqueda, examina los resultados y vuelve a pensar. Ese ciclo de razonamiento, acción y observación está en la base de herramientas como Claude Code y Cursor. Durante algún tiempo, la habilidad demandada fue la ingeniería de prompts, es decir, formular una solicitud de la mejor manera posible. Los modelos que pueden actuar, buscar y leer sus propios resultados plantean una pregunta más importante: ¿qué elige el siguiente movimiento del agente y qué le indica que se detenga?

La ingeniería de bucles es la costumbre de responder a eso de forma intencionada. El diseñador elige el objetivo, las verificaciones y el punto de parada, y luego construye un sistema compacto que expresa el objetivo una sola vez y permite al agente seguir iterando hasta que la tarea se complete. La responsabilidad pasa de instruir al agente paso a paso a crear aquello que las instrucciones requieren.

Se trata de una idea sólida, pero también es donde comienza la parte difícil. Los bucles descuidados consumen recursos sin fin, nunca terminan o se convencen a sí mismos de que están avanzando. Los buenos son eficientes, se detienen en el momento adecuado y generan resultados fiables. Un prompt más inteligente no reduce esa distancia; un bucle mejor sí lo hace.

Los ejemplos a continuación utilizan LangGraph porque facilita ver la estructura de un bucle, pero nada aquí está vinculado a un marco específico. Las mismas ideas se aplican con otro marco de agentes o con código escrito a mano. Los marcos cambian, pero los conceptos permanecen.

Las cinco partes de un bucle de agentes

Antes de decidir cuándo es apropiado utilizar un bucle, es útil saber de qué está compuesto. Casi todos los bucles de agentes tienen cinco partes.

• Un desencadenante. Alguno evento pone en marcha el proceso, como que una persona escriba “ir”, que se active un programador de tareas, que llegue un ticket o que se abra una solicitud de integración. Sin un desencadenante, el agente permanece inactivo.
• Un objetivo verificable. El bucle debe saber cómo se ve el final, de preferencia en una forma que una máquina pueda confirmar. Mejorar la aplicación implica una ejecución interminable: hay que hacer que todas las pruebas den resultado, o bien proporcionar una respuesta cuyas afirmaciones estén todas respaldadas por fuentes, lo que constituye una verdadera línea de meta.
• Herramientas. El agente debe poder actuar y también observar el resultado, ejecutando código y leyendo los errores, o buscando en la web y leyendo los resultados. Si el entorno nunca responde, el agente solo puede adivinar.
• Estado. Este es el panorama actual del trabajo: los intentos realizados hasta ahora, los hallazgos, cuántas rondas han transcurrido. Es la parte más complicada del diseño de bucles, ya que un estado excesivo entierra la señal útil bajo ruido.
• Reglas de detención. Estas definen cómo termina el bucle, y existen tres opciones. El éxito significa que se alcanzó el objetivo. Rendirse implica que se agotó el presupuesto de intentos. Transferir significa que el bucle se topó con algo arriesgado o poco claro y lo pasó a otra persona en lugar de adivinar.

El resto de la discusión, que aborda cuándo aplicar un bucle, cuándo no y cómo hacerlo, se basa en estos cinco puntos.

Cuándo vale la pena usar un bucle

Un bucle resulta útil cuando un solo paso por el modelo no es suficiente, y la tarea realmente requiere que el agente intente, verifique y vuelva a intentar. Cuatro señales indican esto.

• Los resultados pueden verificarse. Esto es lo más importante. Cuando un resultado se puede comprobar automáticamente, ya sea porque las pruebas son exitosas o fallidas, porque una respuesta cita o no fuentes reales, o porque un payload JSON es válido o no, el bucle puede utilizar esa verificación para acercarse a la solución correcta. La verificación funciona como el volante, mientras que un bucle sin ella solo genera gastos innecesarios.
• El primer intento suele estar equivocado, pero es reparable. El código, los borradores de investigación y la limpieza de datos desordenados mejoran con la repetición. El agente crea algo, detecta los defectos y los corrige.
• Nadie sabe cuántos pasos se necesitarán. Un problema de un tipo determinado puede requerir dos pasos hoy y siete mañana. Un proceso fijo no puede adaptarse de esa manera, en contraste con un bucle que continúa hasta alcanzar el objetivo.

Nadie está observando. Tratar los tickets durante la noche o intentar nuevamente una integración inestable hasta que funcione requiere un sistema que elija su próxima acción por sí mismo y no espere una instrucción.

Un ejemplo adecuado es un agente de investigación que audita sus propios hallazgos. Elabora una respuesta, verifica si las fuentes respaldan cada afirmación y vuelve a investigar aquellas débiles. Sigue repitiendo este proceso hasta que la respuesta sea sólida o se alcance un límite. Estos cuatro indicadores están presentes, y este es el agente que se describe más adelante.

Formas comunes de bucles

La mayoría de los bucles de agentes son variaciones de unas pocas formas. Reconocerlas ayuda a identificar cuál es la necesidad del problema antes de conectar cualquier componente.

Generar y verificar, a veces llamado reflexión. Una etapa crea una salida y una segunda la inspecciona, y la pareja repite el proceso hasta que la inspección es exitosa. La señal de dirección es binaria: la verificación aprueba el resultado o indica qué está mal. Es adecuado para situaciones en las que se puede probar la corrección, como código que debe superar pruebas o investigaciones cuyas afirmaciones necesitan respaldo. Esta es la estructura que se construye posteriormente.

   +-----------+      +-----------+
-->| Generate  |----->|  Verify   |----- pass -----> [ done ]
   +-----------+      +-----+-----+
        ^                   |
        +------- fail ------+

Elige esta opción cuando existe una prueba objetiva de corrección y el agente debe seguir reparando hasta que la prueba sea exitosa. Un ejemplo clásico es un agente que escribe consultas SQL, ejecuta sus consultas en bucles hasta que se ejecuten y devuelvan filas plausibles.

Evaluador y optimizador, también denominados generador y calificador. El calificador asigna una puntuación a cada intento en lugar de un simple sí o no, y el bucle busca alcanzar la puntuación más alta y no solo la corrección. Esto es útil cuando no existe una distinción clara entre éxito y fracaso, pero aún se puede medir qué es mejor, como al ajustar un prompt, perfeccionar el texto publicitario o clasificar resultados.

   +-----------+      +-----------+
-->| Generate  |----->|  Score    |--- good enough --> [ done ]
   +-----------+      +-----+-----+
        ^                   |
        +-- improve --------+
            (use the score)

Elige cuando la calidad se mide en una escala pero aún se puede asignarle un número. Redactar un eslogan para un producto, evaluando su claridad y impacto con una puntuación, mientras el bucle perfecciona al mejor candidato, ilustra esta idea.

Planificar, ejecutar, replanificar. Un planificador define los pasos y quienes los ejecutan los llevan a cabo; y cada vez que un paso revela algo inesperado, el bucle vuelve a revisar el plan. El bucle rodea al plan en lugar de a un solo resultado, por lo que es adecuado para trabajos abiertos y de múltiples pasos como la investigación o un proyecto de software.

   +-----------+      +-----------+
-->|   Plan    |----->|  Execute  |-- all steps done --> [ done ]
   +-----------+      +-----+-----+
        ^                   |
        +-- replan ---------+
            (hit a surprise)

Elige esta opción cuando la tarea tiene muchos pasos y no todos son conocibles de antemano. Migrar un servicio a un nuevo framework funciona: se planifican los pasos, se comienza a ejecutar y se vuelven a planificar en cuanto un paso revela una dependencia inesperada.

Bucle programado o de monitoreo. En lugar de iterar hacia un objetivo durante una sola ejecución, esta variante se activa mediante un temporizador o un evento para observar y responder, por ejemplo, para clasificar nuevos tickets, buscar compilaciones defectuosas o intentar nuevamente una tarea poco fiable. Se extiende en el tiempo y no ocurre dentro de una sola tarea.

   +-----------+     +-----------+     +-----------+
-->|   Wait    |---->|   Check   |---->|    Act    |---+
   | (timer /  |     +-----------+     +-----------+   |
   |  trigger) |                                       |
   +-----------+ <-------------------------------------+
        (no fixed end — keeps watching over time)

Elige esta opción cuando no existe una línea de meta única y el objetivo es observar y reaccionar de forma continua, como al revisar el buzón de correo cada pocos minutos o al buscar periódicamente solicitudes de integración obsoletas.

Estas estructuras no son mutuamente excluyentes. Los sistemas reales suelen combinarlas; por ejemplo, un bucle programado que ejecuta pasos de generación y verificación cada vez que se activa. La estructura más común, generar y verificar, es la que se construye de extremo a extremo a continuación.

Crear un bucle con LangGraph

El agente que se debe crear es un investigador que desconfía de su propio primer borrador. Ante una pregunta, recopila información, escribe una respuesta y luego verifica cada afirmación contra fuentes reales. Las afirmaciones que carecen de respaldo se envían de vuelta para más investigación. El ciclo continúa hasta que la respuesta completa sea válida, o hasta alcanzar el límite de intentos, momento en el cual el agente presenta su mejor versión y marca lo que sigue siendo incierto. En resumen, responde y luego se convence a sí mismo de que la respuesta es correcta antes de entregarla.

Ese comportamiento de autoverificación es exactamente el bucle de generar y verificar, por lo que se obtiene una primera versión impecable.

LangGraph es una buena opción porque describe a un agente como un grafo. Los nodos son cajas que realizan tareas, y las aristas son flechas que determinan qué se ejecutará a continuación. Se permite que las aristas apunten hacia atrás, lo que permite la existencia de bucles. Una cadena lineal simple no puede repetirse, pero un grafo sí puede hacerlo.

El investigador tiene tres tareas, por lo que hay tres nodos. Los dos primeros dividen el trabajo entre un creador y un verificador, un ejecutor y un crítico manteniéndolos separados, un patrón común en bucles.

                    +------------------+
  START ----------> |     Research     | <-------------+
                    | (draft / revise) |               |
                    +--------+---------+               |
                             |                         |
                             v                         | needs work
                    +------------------+               | (+ feedback)
                    |      Verify      |               |
                    |  (check claims)  |               |
                    +--------+---------+               |
                             |                         |
                             v                         |
                       +-----------+   needs work      |
                       |  Decide   |-------------------+
                       | (router)  |
                       +-----+-----+
                             | verified / out of tries
                             v
                          [ END ]

1. Investigación: recopila material y elabora un borrador de respuesta.
2. Verificación: revisa el borrador y comprueba si cada afirmación está respaldada por pruebas.
3. Decisión: es un pequeño router que analiza el veredicto y decide qué hacer a continuación: finalizar o volver a investigar los puntos débiles.

El ejemplo funciona con Python 3.12. Se necesitan tres paquetes:

pip install langgraph==1.2.6 langchain-openai==1.3.3 pydantic==2.13.4

• langgraph es el motor de grafos y bucles, que incluye StateGraph, START y END.
• langchain-openai encapsula el modelo de chat de OpenAI como ChatOpenAI.
• pydantic define el veredicto estructurado que devuelve el verificador.

También es necesario que haya una clave API de OpenAI en el entorno antes de ejecutarlo:

export OPENAI_API_KEY="your-key-here"

from typing import TypedDict, Literal
from langgraph.graph import StateGraph, START, END
from langchain_openai import ChatOpenAI
from pydantic import BaseModel, Field

# A model client on OpenAI's Responses API, with the built-in web-search tool
# bound on — so the model can search the web itself, no extra package needed.
# "gpt-5" is a reasoning model; swap it for any current model you have access to.
llm = ChatOpenAI(model="gpt-5", use_responses_api=True)
searcher = llm.bind_tools([{"type": "web_search"}])

MAX_ITERATIONS = 3         # a stop rule, decided up front

# STATE — the shared memory passed between every node
class ResearchState(TypedDict):
    question: str          # what we're answering
    draft: str             # the current best answer
    verdict: str           # "verified" or "needs_work"
    feedback: str          # what the verifier said to fix
    iterations: int        # how many times we've looped

# The verifier returns a typed result, so the router gets a clean
# "verified" / "needs_work" to branch on instead of parsing prose.
class Verdict(BaseModel):
    status: str = Field(description='"verified" or "needs_work"')
    feedback: str = Field(description="claims lacking support, if any")

# NODE 1 — the maker: search the web, then draft (or revise) the answer.
def research(state: ResearchState) -> dict:
    prompt = "Search the web, then answer the question. Back every claim with a source.\n"
    if state.get("feedback"):
        prompt += f"A reviewer flagged these gaps — fix them:\n{state['feedback']}\n"
    prompt += f"\nQuestion: {state['question']}"
    draft = searcher.invoke(prompt).text
    return {"draft": draft, "iterations": state["iterations"] + 1}

# NODE 2 — the checker: search for evidence, then critique the draft.
def verify(state: ResearchState) -> dict:
    evidence = searcher.invoke(
        f"Search the web for evidence to fact-check claims about: {state['question']}"
    ).text
    checker = llm.with_structured_output(Verdict)
    result = checker.invoke(
        "You are a fact-checker. Using the evidence below, reply 'verified' "
        "only if every claim in the answer is supported; otherwise 'needs_work' "
        "and list the unsupported claims as feedback.\n\n"
        f"Evidence:\n{evidence}\n\nAnswer:\n{state['draft']}"
    )
    return {"verdict": result.status, "feedback": result.feedback}

# ROUTER — the heart of the loop. Reads the verdict, picks the next step.
def decide(state: ResearchState) -> Literal["research", "__end__"]:
    if state["verdict"] == "verified":
        return "__end__"                      # success: goal met
    if state["iterations"] >= MAX_ITERATIONS:
        return "__end__"                      # surrender: out of tries
    return "research"                         # loop back and fix the gaps

# WIRE IT UP
graph = StateGraph(ResearchState)
graph.add_node("research", research)
graph.add_node("verify", verify)

graph.add_edge(START, "research")            # trigger
graph.add_edge("research", "verify")         # always verify a fresh draft
graph.add_conditional_edges("verify", decide, {
    "research": "research",                   # the backward arrow = the loop
    "__end__": END,
})

agent = graph.compile()

result = agent.invoke({
    "question": "What were the main causes of the 2008 financial crisis?",
    "draft": "", "verdict": "", "feedback": "", "iterations": 0,
})
print(result["draft"])

Hay dos detalles destacables. Primero: ambos nodos acceden a la web en tiempo real a través de la herramienta integrada web_search de OpenAI, conectada mediante bind_tools. El nodo research realiza búsquedas antes de redactar para que sus afirmaciones se basen en resultados reales. El nodo verify busca una segunda vez para probar el borrador con evidencias actualizadas en lugar de con la memoria del modelo, y es esa segunda búsqueda la que proporciona una señal objetiva al ciclo. Segundo: verify depende de with_structured_output, que exige un verdict y feedback estructurados en lugar de texto narrativo, de modo que el enrutador pueda tomar decisiones de forma fiable sin tener que analizar texto libre.

Las cinco partes del ciclo se corresponden claramente con el código:

• Desencadenante: llamar a invoke(...) con una pregunta inicia una ejecución.
• Objetivo verificable: las reglas verify deben estar marcadas como verified o needs_work.
• Herramientas: ambos nodos utilizan la búsqueda web integrada, research para redactar y verify para comprobar.
• Estado: el diccionario ResearchState traslada el borrador, los comentarios y el recuento de iteraciones entre los nodos.
• Reglas de detención: el enrutador decide finaliza el proceso al lograr éxito o al alcanzar MAX_ITERATIONS.

El último punto es fundamental, ya que el enrutador es donde realmente se lleva a cabo la ingeniería de bucles. Una sola línea, como “detenerse si se verifica, detenerse después de tres intentos, de lo contrario volver atrás”, permite distinguir a un agente que mejora de manera fiable su respuesta de uno que sigue ejecutándose indefinidamente.

El ejemplo tiene dos salidas. Los bucles de producción tienden a añadir una tercera, una transferencia a un humano. Al encontrarse con algo arriesgado o poco claro, es mejor para el agente no adivinar ni detenerse en silencio, sino detenerse y elevar la situación con toda la información recopilada. En el enrutador esto es simplemente otra rama: cuando la confianza es baja o la acción es delicada, una ruta escalate termina el bucle y presenta el borrador, las preguntas pendientes y los intentos realizados. Saber cuándo no tomar una decisión forma parte de un buen diseño de bucles.

Modos de fallo y sus mecanismos de protección

Una vez que un bucle funciona por sí solo, aparece una lista corta de fallos predecibles, y cada uno tiene un mecanismo de protección estándar.

• El bucle infinito. El agente nunca considera que ha terminado y sigue actuando hasta que algo falla o se agota el dinero. La limitación de iteraciones es un límite estricto, como MAX_ITERATIONS mencionado anteriormente, una salida que no depende de la opinión del propio agente.
• Quema de tokens. Cada paso vuelve a enviar una cantidad cada vez mayor de contexto, y el costo aumenta sin que se note. Mantén el estado ligero llevando solo lo que requiere el siguiente paso: el borrador actual y los comentarios específicos, pero nunca toda la historia.
• Progreso imaginario. El agente anuncia éxitos que no ha logrado, como afirmar que se ha corregido algo que nunca ocurrió. No dejes que marque como completado su propio trabajo en los aspectos realmente importantes. Un paso de verificación separado con pruebas objetivas, pruebas que se ejecuten realmente o fuentes que existan de verdad, asegura que lo hecho realmente esté hecho.

Repetición de un mismo error. El bucle vuelve a intentar la misma acción fallida y recibe el mismo resultado negativo. Es necesario pasar el error anterior al siguiente intento para que se modifique el enfoque; por eso research recibe el feedback del verificador.

Acciones sin rendición de cuentas. Con ejecuciones prolongadas resulta difícil determinar qué ocurrió y por qué. Es preciso registrar cada paso: lo que vio, decidió y hizo el agente. La observabilidad deja de ser opcional en cuanto un bucle afecta algo importante, y existen herramientas como LangSmith para rastrear dichas ejecuciones.

Autonomía total desde el principio. Un bucle que opera sin supervisión desde el primer día aún no ha ganado confianza. Es necesario introducirlo gradualmente: primero en modo de solo informes que indique qué haría, luego con cambios asistidos que una persona aprueba, y finalmente con operación sin intervención humana; cada etapa se logra antes de pasar a la siguiente.

Cuándo no construir un bucle

Los bucles son poderosos, por lo que se utilizan en exceso con facilidad. En estas situaciones, algo más simple es mejor.

• Una sola pasada es suficiente. Resumir un documento, traducir texto, responder a una pregunta factual y clasificar un correo electrónico son tareas que se realizan de una sola vez. Un bucle alrededor de ellas solo añade costos, retrasos y nuevas posibilidades de fracaso. Si una secuencia directa de pasos funciona, úsala.
• El éxito es irreconocible. Cuando el objetivo es subjetivo o vago, o solo un ser humano puede juzgarlo, el bucle no tiene nada a lo que agarrarse y terminará de forma arbitraria o girará sin fin. Un objetivo que no se puede verificar convierte algo en una máquina tragamonedas, no en un bucle.

Los errores son costosos o permanentes. Un bucle que envía correos electrónicos, transfiere dinero o elimina datos en cada iteración puede causar daños reales rápidamente. Mantenga a una persona en el proceso de aprobación, o no ejecute el bucle para la acción consecuente.

La velocidad y el costo tienen prioridad sobre la autonomía. Cada iteración implica llamadas adicionales, tokens y tiempo. En una función de alto volumen, con márgenes reducidos o sensible a la latencia, una llamada sencilla y predecible suele ser mejor que un bucle ingenioso pero costoso.

Una regla práctica: si las condiciones para el éxito y para rendirse no se pueden escribir, el bucle aún no está listo para ser desarrollado.

Una lista de verificación antes de usar un bucle

La ingeniería de bucles reubicaría el punto de pago. Escribir una instrucción impecable tiene menos importancia que diseñar el sistema que dirige al agente, es decir, su desencadenante, objetivo, herramientas, estado y reglas de detención. Aun así, un bucle es solo una herramienta entre otras y nunca es la opción por defecto. Cinco preguntas merecen hacerse primero:

1. ¿Se puede verificar el éxito automáticamente? Si no, omite el bucle, ya que no tendría nada en qué basarse para guiarlo.
2. ¿La tarea mejora con la repetición? Si una sola pasada es suficiente, mantén las cosas simples.
3. ¿Qué significa exactamente “terminado”? Escribe la condición de éxito antes de programar.
4. ¿Cuándo debe detenerse? Establece un límite estricto para que el bucle no pueda ejecutarse eternamente.
5. ¿Se pueden repetir las acciones de forma segura? Si una iteración podría causar daños reales, agrega un punto de control humano o no uses bucle en ese paso.

Con respuestas honestas a las cinco preguntas, el resultado puede ser un ciclo fiable y no solo uno superficial. Un primer proyecto modesto funciona mejor: una ronda de investigación y verificación como se describió anteriormente, con reglas de detención establecidas antes de que nada crezca en complejidad.

Un último punto: un ciclo hace más que acelerar el trabajo. Amplifica cualquier juicio que se haya aplicado, repitiendo tanto las buenas como las malas decisiones a la velocidad de la máquina. Por lo tanto, el objetivo no es crearlo y dejarlo así. La disciplina consiste en mantenerse lo suficientemente cerca como para seguir comprendiendo qué hace el ciclo una vez que comienza a funcionar por sí solo, de modo que su diseñador siga siendo su ingeniero y no solo la persona que pulsa el botón de inicio.

Leer más

• Harness, Loop y Graph: Tres capas anidadas en un sistema de agentes de programación — Un síntoma de fallo indica la capa que debe corregirse. Cómo se anidan harness, loop y graph, dónde es útil el enfoque multiagente, qué no pueden garantizar las verificaciones adversarias, y una lista de verificación.
• Ingeniería de loop: Cuatro bucles anidados para agentes de IA auto-mejorables — Cómo cuatro bucles de control anidados (ReAct, retry, queue, hill climbing) junto con un juez, un medidor de presupuesto y una verificación contra manipulaciones hacen que un agente sea fiable, ilustrado en el proceso de aprobación de seguros.

Notas prácticas: El exploit de sys.exit(0): cómo los agentes de IA falsifican el éxito — Guía paso a paso de las Notas prácticas: El exploit de sys.exit(0): cómo los agentes de IA falsifican el éxito: contratos, verificaciones y espacios para código listo para usar para los equipos que implementan este patrón.

Notas prácticas: Ingeniería de una plataforma de IA multiagente — Parte 5: La percepción — Guía paso a paso de las Notas prácticas: Ingeniería de una plataforma de IA multiagente — Parte 5: La percepción: contratos, verificaciones y espacios para código listo para usar para los equipos que implementan este patrón.

Notas prácticas: Ingeniería de bucles de agentes: Un blog completo hasta la IA en producción — Guía paso a paso de las Notas prácticas: Ingeniería de bucles de agentes: Un blog completo hasta la IA en producción: contratos, verificaciones y espacios para código listo para usar para los equipos que implementan este patrón.