Loop engineering: cómo diseñar el bucle de un agente que sabe cuándo parar
Cómo funciona el bucle de un agente de IA: de los ciclos observar-actuar y el estado a las condiciones de parada, los límites de reintentos, el control de costes y las métricas, más una comparación entre diseños sin control y controlados.
Alrededor de cualquier modelo de IA hay un conjunto de piezas de apoyo, y una de las más importantes es el bucle del agente. Aquí nos centramos en ese bucle y en cómo construirlo para que el agente se comporte de forma predecible, no se dispare de precio y sepa cuándo dejarlo.
De una llamada a un ciclo
Un chatbot sencillo suele seguir un único camino recto:
User → LLM → Response
Un agente lo tiene más difícil. Terminar una tarea puede requerir varios pasos, y tras cada uno el modelo mira qué ha pasado:
User
↓
Understand the task
↓
Decide what to do
↓
Use a tool
↓
Observe the result
↓
Decide what to do next
↓
Use another tool
↓
Evaluate the result
↓
Finish
De esa repetición se ocupa el loop engineering.
El bucle de un agente es el ciclo en el que un agente de IA hace una y otra vez lo siguiente:
- Recibe información.
- Elige qué hacer.
- Ejecuta una acción.
- Observa el resultado.
- Juzga si hace falta otra acción.
- Se detiene, en algún momento.
De forma simplificada, el ciclo se ve así:
┌───────────┐
│ Observe │
└─────┬─────┘
↓
┌───────────┐
│ Decide │
└─────┬─────┘
↓
┌───────────┐
│ Act │
└─────┬─────┘
↓
┌───────────┐
│ Observe │
│ Result │
└─────┬─────┘
↓
Finished?
/ \
No Yes
↓ ↓
Decide Stop
Lo importante es que una sola llamada al modelo no tiene por qué dar la respuesta final. El agente puede actuar, aprender de lo que vuelve y seguir.
Un ejemplo pequeño: el tiempo en Bristol
Supongamos que alguien pregunta: «¿Qué tiempo hace en Bristol y debería llevar paraguas?». Un agente puede resolverlo en unos pocos movimientos. Recibe la pregunta y deduce que necesita datos actuales. Luego llama a una API meteorológica, que devuelve esto:
Temperature: 16°C
Condition: Heavy rain
Con eso, el agente ya tiene lo que necesita y responde que en Bristol está lloviendo, así que llevar paraguas es buena idea. Incluso una petición tan pequeña necesitó más de una operación.
También hay tareas simples. Una pregunta como «¿Cuánto es 15 × 20?» necesita una sola operación. Una petición más pesada sería: «Busca tres universidades británicas que ofrezcan un MSc en Data Science y compara sus tasas de matrícula y requisitos de acceso». Eso podría requerir una secuencia como esta:
Search University A
↓
Read information
↓
Search University B
↓
Read information
↓
Search University C
↓
Read information
↓
Compare results
↓
Generate answer
Ninguna respuesta aislada de un modelo de lenguaje puede cubrir todo eso de forma fiable. El bucle permite al agente dividir una tarea grande en acciones pequeñas.
El agente como máquina de estados
La situación del agente puede describirse como un estado. Sea s_t el estado en el instante t. En cada paso, el agente recibe una observación o_t, elige una acción a_t y el mundo pasa a su siguiente estado:
En esa expresión, s_t es el estado actual, o_t la observación actual, a_t la acción, f la función de transición de estados y s_{t+1} el estado siguiente. La elección de la acción también puede escribirse de forma compacta:
Aquí la letra griega pi representa la política de decisión. En un agente basado en un LLM, el modelo forma parte de esa política. Una instantánea podría verse así:
State:
"We need the current weather."
Observation:
"Weather tool is available."
Action:
"Call weather(location='Bristol')"
Y después de que responda la herramienta:
New observation:
"16°C, heavy rain"
Next action:
"Generate final response"
Ver al agente de esta manera, como un sistema que cambia de estado, resulta más útil que pensar en él como un chatbot con pasos extra.
Saber cuándo parar
Quizá la pregunta más difícil en el diseño del bucle sea cómo decide un agente que ha terminado. Imagina un agente atascado haciendo esto:
Call search
↓
Get result
↓
Call search again
↓
Get result
↓
Call search again
↓
...
Sin una regla de salida, podría seguir para siempre. Por eso un agente en producción necesita condiciones de terminación. Hay varias habituales.
La primera es el camino feliz, cuando la tarea está hecha:
Task completed → STOP
La segunda es un presupuesto de pasos, por ejemplo un máximo de cinco:
Maximum steps = 5
Si el agente llega a cinco pasos sin terminar, se detiene:
STOP
La tercera son los fallos repetidos de una herramienta, que deberían terminar la ejecución o pasársela a otra persona:
Tool failed repeatedly → STOP / ESCALATE
La cuarta es una acción arriesgada, en la que una persona tiene que dar su aprobación antes de que ocurra nada:
High-risk action → STOP → Ask human
Coste, latencia y fiabilidad
Trata cada paso como algo que cuesta dinero. Supongamos que el precio por paso es este:
Una ejecución normal de 10 pasos cuesta entonces más o menos esto:
Un bug que provoque 1000 pasos cambia el total de forma drástica:
Para una sola petición, eso ya puede ser un mal trago.
Multiplícalo por miles de usuarios y el problema salta a la vista. Por eso el loop engineering va tanto de coste, latencia y fiabilidad como de funcionalidad.
Gestionar los fallos
Los sistemas reales se rompen. Imagina que la llamada del tiempo devuelve esto:
Error: API unavailable
Un agente mal diseñado simplemente falla. Un bucle mejor reacciona al error:
Tool call
↓
Error
↓
Retry?
┌─┴─┐
Yes No
↓ ↓
Retry Escalate
Los reintentos también necesitan límites. Por ejemplo, tras dos fallos el sistema puede parar en lugar de enviar la misma petición condenada una y otra vez.
Dónde aparecen los bucles
Los bucles de agentes aparecen en muchos ámbitos. Estos son cinco ciclos típicos.
Investigación:
Search → Read → Compare → Search again → Summarise
Programación:
Read code → Modify code → Run tests → Observe errors → Fix → Test again
Análisis de datos:
Inspect data → Run analysis → Observe result → Create visualisation → Explain
Atención al cliente:
Understand issue → Search knowledge base → Check customer data → Respond
Uso del ordenador:
Observe screen → Decide action → Click/type → Observe new screen → Continue
El hilo común es sencillo: actuar, observar el resultado y luego decidir qué viene después.
Bucles sin control frente a bucles controlados
Comparemos dos diseños. El primero le da una herramienta al modelo y lo deja correr:
LLM
↓
Tool
↓
LLM
↓
Tool
↓
LLM
↓
Tool
↓
...
Ahí nada controla nada. El segundo diseño añade puntos de control alrededor de cada paso:
Task
↓
Observe
↓
Decide
↓
Validate action
↓
Execute
↓
Observe result
↓
Evaluate
↓
┌───────────────┐
│ Goal complete?│
└───────┬───────┘
Yes│ No
↓ ↓
Stop Continue
El segundo diseño introduce control, y ese es el núcleo del loop engineering.
Medir un bucle
El éxito no debería juzgarse solo por si al final aparece una respuesta. Aquí hay algunas medidas útiles:
Otras cifras que conviene seguir:
- cuánto tarda una tarea (latencia)
- tokens consumidos
- lo que cuesta cada tarea terminada
- con qué frecuencia se reintentan las llamadas
- la proporción de tareas completadas
- con qué frecuencia tiene que intervenir una persona
En conjunto, estas cifras muestran si un agente está mejorando de verdad.
El compromiso del número de pasos
Los pasos extra permiten a un agente abordar problemas más difíciles. También traen más coste, esperas más largas, más ocasiones de error, más fallos de herramientas y un comportamiento menos predecible. Así que el objetivo no es que el agente dé tantos pasos como pueda. El objetivo es completar la tarea con el menor número de pasos que siga funcionando de forma fiable.
Qué necesita un bucle fiable
Loop engineering significa diseñar y controlar el ciclo de ejecución repetitivo de un agente de IA. El patrón básico funciona así:
Se repite hasta que la tarea está hecha o el sistema decide detenerse. Un agente fiable necesita estos ingredientes:
- acciones bien definidas
- iteraciones que alguien controla
- condiciones de parada explícitas
- gestión de errores
- topes de reintentos
- estado gestionado
- límites de gasto
- evaluación continua
Autonomía no significa ejecución ilimitada. Un buen agente sabe qué hacer a continuación y también cuándo parar.
Un modelo potente y un bucle ingenioso pueden fallar igualmente si al agente le llega la información equivocada. Eso lleva a la siguiente pregunta: ¿qué debería recibir realmente un agente en cada paso? La respuesta corresponde al context engineering, que trata de dar a los agentes la información adecuada en el momento adecuado.