El problema
03:07 de la madrugada.
El ingeniero on-call ve que el agente recibió una solicitud normal, llamó varias veces a un tool, recibió resultados, pero aun así no pudo terminar la tarea.
En los logs se repite:
plan → call_tool → analyze → plan → call_tool → analyze
Muchos pasos, muchos tokens, ningún resultado.
El agente intenta encontrar un email en el CRM. La búsqueda devuelve 404, pero en lugar de responder "no encontrado", el agente empieza a cambiar la consulta:
john@example.comJohn@example.comJOHN@example.comjohn@company.com
En 2 minutos, el agente hizo 47 llamadas API, gastó cerca de $5 en tokens y aun así no se acercó a una respuesta.
Un runaway loop puede quemar en 30-40 minutos un presupuesto pensado para una semana completa.
Analogía: imagina a un cajero que pasa el mismo producto una y otra vez, ignorando el límite de la tarjeta del cliente. Puede parecer "ocupado", pero cada acción nueva solo aumenta la pérdida. En agentes de IA, runtime cumple ese rol de control: stop conditions, presupuestos y policy gates.
Por qué pasa
En producción:
- el LLM propone el siguiente paso;
- se ejecuta una llamada al tool;
- el resultado vuelve al reasoning loop;
- runtime no verifica progreso real y no detiene el ciclo a tiempo.
El problema no es el modelo. El problema es que runtime no sabe cuándo parar.
Qué fallos aparecen con más frecuencia
Para no complicar el análisis, en producción normalmente se empieza por tres tipos principales de fallos.
Fallos de bucle (Loop failures)
El agente repite los mismos pasos sin observaciones nuevas. Desde fuera puede parecer que sigue trabajando, pero en realidad el sistema gira en círculo y quema tiempo y dinero.
Causa típica: falta max_steps, falta progress check o no hay stop reason claro.
En producción, esto suele verse como un bucle infinito.
Fallos de herramientas (Tool failures)
El agente llama herramientas con demasiada frecuencia o de forma incorrecta. Aumentan la latencia y la carga API, y los fallos se propagan por la cadena de servicios.
Causa típica: Tool Execution Layer demasiado permisiva y validación débil de argumentos.
El resultado suele ser un fallo de herramienta.
Fallos de presupuesto (Budget failures)
El presupuesto de tokens y tiempo crece sin progreso visible. Como resultado, el sistema se vuelve más caro y los servicios dependientes chocan más con timeouts.
Causa típica: no hay execution budgets para pasos, tokens, tiempo y número de llamadas tool.
Sin límites, esto suele escalar a una explosión de presupuesto.
Deriva de contexto (Context drift)
Cuando un agente trabaja demasiado tiempo, el historial de mensajes crece. Los nuevos tokens pueden desplazar el system prompt, y el agente empieza a "olvidar" su rol o la tarea original. Esto es context drift. Normalmente se corrige con summarization y límites del context window; un escenario cercano por síntomas es envenenamiento de contexto.
Además, conviene vigilar dos clases más:
Security failures: prompt injection y acceso no autorizado a herramientas de escritura.Data failures: datos intermedios incorrectos o no validados que rompen la respuesta final.
Cómo detectar estos problemas
Para atrapar estos fallos antes de que sean incidentes, los sistemas de producción suelen monitorear unas pocas métricas clave.
| Métrica | Señal | Qué hacer |
|---|---|---|
steps_per_task | subida brusca de iteraciones | revisar stop conditions, añadir progress check |
tool_calls_per_task | demasiadas repeticiones sospechosas | introducir dedupe de tool+args y límites de llamadas |
tokens_per_task | el gasto sube sin progreso | limitar context window, añadir summarization y caps para tool output |
runtime_duration | sube la latencia, la tarea se atasca | timeout y finalización forzada del run |
Cómo distinguir un fallo de una tarea realmente difícil
No todo run largo significa fallo. La señal clave no es la cantidad de pasos, sino la ausencia de progreso real.
Es normal si:
- los pasos
toolcambian las observaciones; - aparecen datos nuevos;
- el resultado se acerca a
final_answer.
Es peligroso si:
- hay repeticiones sin observaciones nuevas;
- el mismo
tool_callse repite sin cambios en argumentos; - el costo sube, pero el resultado no mejora.
Cómo detener estos fallos
La forma más simple de controlar el execution loop es con límites de runtime. Normalmente: max_steps, max_tool_calls, max_tokens y timeout.
max_steps es el primer freno de emergencia contra runaway loops. Una opción más avanzada es semantic progress check: un modelo pequeño aparte (por ejemplo, Gemini Flash o Claude Haiku) analiza los últimos 3 pasos del agente y verifica si apareció una señal nueva o si el sistema solo está girando. El resultado puede verse así:
{
"is_progressing": true,
"is_looping": false
}
Un esqueleto básico de runtime que cubre la mayoría de runaway loops:
class RunLimits:
def __init__(self):
self.max_steps = 8
self.max_tool_calls = 12
self.max_tokens = 4000
self.max_seconds = 30
self.steps = 0
self.tool_calls = 0
def check(self, step_tokens: int, elapsed_ms: int) -> str | None:
self.steps += 1
self.max_tokens -= step_tokens
if self.steps > self.max_steps:
return "max_steps_reached"
if self.tool_calls > self.max_tool_calls:
return "max_tool_calls_reached"
if self.max_tokens <= 0:
return "max_tokens_reached"
if elapsed_ms > self.max_seconds * 1000:
return "timeout"
return None
def register_tool(self):
self.tool_calls += 1
En producción, estos límites suelen guardarse en Redis para aplicarlos entre stateless workers.
Pero los límites por sí solos no garantizan comportamiento correcto: solo detienen el runaway loop. Para estabilidad real también hacen falta validación de tool output, policy boundaries y control sobre acciones de escritura.
Autoevaluación
Verificación rápida antes del release. Marca los puntos y mira el estado abajo.
Este es un sanity-check corto, no una auditoría formal.
Progreso: 0/8
⚠ Hay señales de riesgo
Faltan controles básicos. Cierra los puntos clave del checklist antes del release.
FAQ
Q: ¿Por qué los agentes de IA fallan más que los workflows normales?
A: En workflow los pasos están fijados de antemano. En un agente, el LLM propone el siguiente paso de forma dinámica y, sin límites de runtime, el ciclo se descontrola rápido.
Q: ¿Cambiar a un modelo más potente resuelve esto?
A: Puede ayudar parcialmente, pero no resuelve la raíz. Sin control de runtime, incluso un modelo fuerte puede entrar en bucle, exceder presupuesto o hacer spam de herramientas.
Si el agente del inicio hubiera tenido max_steps = 8 y dedupe para tool+args, el incidente de las 03:07 habría terminado en segundos.
En producción, la estabilidad del agente no la define el modelo, sino los límites que runtime pone alrededor del execution loop.
Páginas relacionadas
Para entender mejor cómo prevenir estos fallos, revisa las capas del sistema que controlan el comportamiento del agente:
- Agent Runtime - controla el ciclo del agente, límites y motivos de parada.
- Tool Execution Layer - ejecuta
tool_callde forma segura con validación, policy y timeout. - Policy Boundaries - define qué acciones se permiten y cuáles se bloquean por defecto.
- Memory Layer - ayuda a mantener el estado limpio para que el agente no repita pasos sin progreso.
También es útil ir a escenarios de fallo específicos:
- Infinite loop - cómo detectar y detener repeticiones sin progreso.
- Tool spam - cómo limitar llamadas de herramienta duplicadas.
- Budget explosion - cómo controlar gasto de tokens y presupuesto API.