Un fallo costoso y habitual en sistemas de IA de producción: son las 3 de la madrugada del martes y un agente de atención al cliente entra en un bucle infinito. Invoca la misma herramienta, recibe el mismo error, reintenta con un parámetro ligeramente distinto y vuelve a obtener el mismo resultado. Lo repite cientos de veces por minuto. Al amanecer, el equipo se encuentra con una factura inesperada de cuatro o cinco cifras, según el modelo y la frecuencia de las llamadas.
No es un caso excepcional. Los bucles son uno de los fallos más comunes y graves en producción. Resultan insidiosos porque el agente parece estar trabajando: ejecuta acciones y las llamadas terminan con éxito o fallan de forma predecible. Solo al revisar la traza se hace visible el patrón repetido.
Construir agentes que no entren en bucles infinitos requiere decisiones arquitectónicas deliberadas. La mayoría de los fallos de agentes son predecibles; los patrones para evitarlos son bien conocidos. Los equipos que implementan agentes confiables son los que aplican estos patrones con rigor.
Este artículo cubre qué hace que los agentes entren en bucles, los patrones arquitectónicos que los evitan y las medidas de protección operativas que detectan los bucles cuando se filtran.
Por qué los agentes entran en bucles
Algunos mecanismos detrás de los bucles de agentes:
1. Confusión sobre el progreso
El agente no sabe responder con claridad a «¿he avanzado?». Prueba algo, observa el resultado y decide intentar otra cosa. Sin un seguimiento explícito del progreso, esa «otra cosa» puede ser la misma acción con una variación mínima.
2. Falta de criterios de terminación
El prompt del agente dice “ayuda al usuario”, pero no dice “detente cuando X sea cierto”. Sin criterios claros de terminación, el agente sigue “ayudando” — buscando otra pieza de información, intentando otra herramienta, refinando aún más.
3. Patología de reintento
Cuando algo falla, los agentes suelen reintentar. Sin presupuestos de reintento, el mismo fallo puede repetirse indefinidamente. El agente percibe “aún no he tenido éxito” en lugar de “ya he intentado esto 10 veces”.
4. Amnesia del estado
La memoria de trabajo solo conserva los últimos pasos. Tras 20 intentos, el agente quizá vea únicamente los últimos 5 y no detecte un patrón que resulta obvio desde fuera.
5. Inconsistencia de herramientas
Una herramienta devuelve resultados confusos o contradictorios. El agente vuelve a intentarlo. La herramienta sigue devolviendo resultados confusos. El agente razona “tal vez mi interpretación anterior estaba equivocada” y lo intenta de otra manera. La herramienta sigue devolviendo resultados confusos. Bucle.
6. Optimismo excesivo
La formación del agente lo hace persistente — sigue intentando cuando una mejor estrategia sería detenerse y pedir ayuda. Especialmente grave en tareas de horizonte largo donde las confusiones pequeñas se acumulan.
7. Deriva de objetivos
El agente pierde gradualmente de vista lo que intentaba lograr. Se ramifica en subtareas, luego en subtareas de subtareas, explorando áreas tangencialmente relacionadas sin volver al objetivo principal.
Diferentes agentes fallan de diferentes maneras. Las defensas se solapan.
Patrón 1: Presupuesto estricto de pasos
La defensa más sencilla e importante es fijar un máximo de pasos. Si el agente dispone de 20 llamadas a herramientas, al alcanzar 20 debe producir una respuesta final o derivar la tarea.
Implementación:
def agent_loop(query, max_steps=20):
messages = [{"role": "user", "content": query}]
for step in range(max_steps):
response = call_llm(messages, tools=available_tools)
if response.is_final_answer:
return response.content
result = execute_tool(response.tool_call)
messages.append(response)
messages.append({"role": "tool", "content": result})
# Hit budget — force final answer
return force_final_answer(messages)
El presupuesto debe calibrarse según la tarea. Tareas simples: 5-10 pasos. Tareas complejas de múltiples fuentes: 20-30. Investigación abierta: 50+. Pero siempre acotado.
Cuando se alcanza el presupuesto, el agente produce su mejor respuesta con lo que sabe. O escala a un humano.
Este patrón por sí solo evita la mayoría de los bucles catastróficos. Aplícalo siempre.
Variantes
Presupuesto de tokens. En lugar de (o además de) el recuento de pasos, limita el número total de tokens. Evita agentes que toman menos pasos pero cada paso es una traza de razonamiento de 50K tokens.
Presupuesto de costes. Convierte los límites de pasos y tokens en euros para que el riesgo económico sea explícito.
Presupuesto de tiempo. Límite de reloj real. Útil para flujos orientados al usuario (“responde dentro de 30 segundos”).
La mayoría de los agentes de producción tienen los cuatro presupuestos en alguna forma. Al alcanzar cualquiera de ellos, se detiene la ejecución.
Patrón 2: Seguimiento del progreso
Un presupuesto únicamente detiene al agente cuando se agota. El seguimiento del progreso le permite reconocer antes el bucle y salir de él.
Una implementación simple: el agente mantiene un registro explícito de “progreso”. En cada paso, establece qué nueva información obtuvo o qué cambió.
Step 1: Searched for customer "Smith". Found 12 matches.
Step 2: Filtered to active accounts. 4 remain.
Step 3: Checked recent activity. Customer 234 had a recent ticket about pricing.
Step 4: Pulled the ticket details. The complaint was about a recent price change.
Step 5: Drafted response. Ready to send.
Cada paso añade información nueva. Si llega al paso 6 sin que el registro cambie —misma búsqueda, mismos resultados y misma conclusión—, está girando en círculos.
El prompt puede incluir:
Before deciding the next action, summarize what you've learned in the last few steps. If you haven't gained new information in the last 3 steps, stop and either:
- Produce your best answer with current information.
- Escalate the issue: explain what you've tried and what's missing.
Esto hace visible la “falta de progreso” para el agente para que pueda reaccionar.
Patrón 3: Detección de repeticiones
A veces los agentes repiten exactamente la misma llamada a herramienta. Es fácil detectarlo programáticamente.
def detect_repeat(history):
recent_calls = [c for c in history[-5:] if c.is_tool_call]
if len(recent_calls) < 3:
return False
call_signatures = [(c.tool, json.dumps(c.args, sort_keys=True)) for c in recent_calls]
return len(set(call_signatures)) < len(call_signatures) / 2
Si detectas una repetición, intervén:
- Inyecta un mensaje: “Has llamado a esta herramienta con estos parámetros recientemente. Los resultados no han cambiado. Inténtalo de otra manera o termina.”
- O fuerza la terminación.
Esto detecta automáticamente los bucles más obvios.
Patrón 4: Detección de estados atascados
Más allá de las repeticiones exactas, se pueden detectar estados atascados más sutiles:
Reconocimiento de patrones. Utiliza una llamada independiente a un LLM para evaluar: «Al observar los últimos 5 pasos, ¿está avanzando el agente?». Si la respuesta es no, deténlo.
def is_stuck(history):
recent = format_history(history[-5:])
response = call_llm(
system="You are evaluating whether an agent is making progress.",
user=f"Recent agent steps:\n{recent}\n\nIs the agent making meaningful progress or stuck in a loop? Answer: progressing | stuck."
)
return response.content.strip() == "stuck"
Ejecuta esta comprobación cada pocos pasos. Si devuelve «atascado», intervén.
Diversidad de herramientas. Si el agente solo ha invocado 1 herramienta durante 5+ pasos, es una señal sospechosa. Oblígalo a probar otro enfoque o a detenerse.
Patrones de error. Si la misma herramienta devuelve el mismo error 3+ veces, desactívala. Más reintentos no harán que el agente descubra la entrada que falta.
Patrón 5: Puntos de reflexión
En puntos específicos de la ejecución del agente, fuerza una reflexión explícita.
After every 5 steps, the agent must produce a reflection:
1. What was my original goal?
2. What have I learned so far?
3. What do I still need to know?
4. Am I making progress, or repeating?
5. Should I continue or stop?
La reflexión obliga al agente a apartarse de la siguiente acción inmediata y evaluar la situación general.
Resulta especialmente eficaz en tareas de horizonte largo. Sin reflexión forzada, los agentes se desvían; con ella, pueden detectar la deriva.
Patrón 6: Anclaje del objetivo
En ejecuciones largas de agentes, el objetivo original se pierde. La ventana de contexto del agente se llena con pasos intermedios; la pregunta original se vuelve una pequeña parte de un contexto grande.
Contrarresta esto anclando el objetivo repetidamente:
- Incluye el objetivo original al principio de cada mensaje del sistema.
- Haz que el agente repita el objetivo cada N pasos.
- Usa un “registrador de objetivos” separado que confirme que cada paso está alineado con el objetivo.
Ejemplo de adición al prompt:
Original goal: [verbatim user request]
Before each action, confirm:
- Is this action helping me toward the original goal?
- If yes, proceed.
- If no, return to the goal directly.
Patrón 7: Delimitación de subtareas
Los agentes largos se dividen naturalmente en subtareas. Sin estructura, las subtareas pueden generar subtareas de subtareas de forma recursiva hasta que el agente se pierde.
Proporciona estructura:
- El agente identifica subtareas explícitamente.
- Cada subtarea tiene su propio presupuesto.
- Después de completar (o fallar) una subtarea, el agente vuelve a la tarea principal.
- Las subtareas no pueden generar subtareas sin límite.
Esto es lo que formalizan frameworks como LangGraph: una máquina de estados en la que cada nodo representa un paso claro y las transiciones son explícitas.
Para agentes complejos, esta estructura es esencial. Para agentes simples, es excesiva.
Patrón 8: Salidas de emergencia
Cuando un agente se atasca, necesita formas explícitas de detenerse:
Escalar. “No puedo completar esta tarea. Aquí está lo que he intentado y lo que falta.” El agente se detiene y presenta el problema.
Completación parcial. “He completado las partes A y B. C está bloqueado por X.” El agente no tiene que tener éxito completamente; puede producir una salida útil parcial.
Clarificación. “Necesito más información del usuario: …” El agente se detiene y pregunta.
Estas deben ser opciones de primer nivel, no recursos de última hora. El prompt debe mencionarlas y fomentar su uso cuando el agente se atasque.
Una adición útil al prompt:
If you encounter any of these situations, stop trying and respond appropriately:
- A tool consistently returns the same error.
- You've tried 3 different approaches without progress.
- You need information only the user can provide.
- The task is more complex than your tools support.
In these cases:
- For tool errors: explain the issue, suggest the user contacts support.
- For lack of progress: report what you've tried and ask for guidance.
- For missing information: ask the user a specific question.
- For complexity: escalate to human assistance with a summary.
Patrón 9: Acciones conscientes de confianza
El agente debe saber cuándo está confiado y cuándo no. Actuar con baja confianza es cómo empiezan los bucles.
Un patrón: cada acción importante requiere confianza explícita.
Before calling delete_record, state your confidence on a 1-5 scale that this is the right action. If <4, do not call. Instead, ask for human confirmation.
Esto funciona especialmente bien para acciones destructivas o costosas. El agente debe comprometerse con una alta confianza antes de tomarlas.
Combinado con la reflexión, esto detecta casos donde el agente está “intentando cosas” en lugar de “ejecutar un plan.”
Patrón 10: Protecciones a nivel de herramienta
Más allá de los patrones a nivel de agente, las herramientas mismas pueden tener protecciones:
Límites de tasa por sesión. Una herramienta solo puede llamarse N veces por sesión. Después de N, devuelve “límite de tasa”. Obliga al agente a hacer algo más.
Idempotencia. Llamadas idénticas repetidas devuelven el resultado almacenado sin reejecutar. Evita bucles que golpean una herramienta.
Límites de coste. Herramientas costosas (consultas pesadas a bases de datos, APIs de terceros con costes de uso) tienen límites por sesión.
Interruptores de circuito. Una herramienta que ha fallado 3 veces durante la sesión se desactiva y el agente deja de poder invocarla.
Estas complementan los patrones a nivel de agente. El agente podría intentar bucles, pero la herramienta lo evita.
Patrón 11: Monitorización externa
Para todos los patrones internos del agente, un monitor externo captura lo que se filtra.
Un proceso independiente vigila todos los agentes en ejecución y comprueba:
- Cantidad de pasos por agente.
- Uso de tokens por agente.
- Costo por agente.
- Tiempo por agente.
- Patrones de llamadas a herramientas.
Cuando un agente supera los umbrales, detiene su ejecución y envía una alerta.
Esta es la última línea de defensa. Aunque el agente presente un fallo, el monitor lo detiene antes de que agote el presupuesto.
En implementación:
- Una base de datos de series temporales registra métricas del agente.
- Las reglas activan órdenes de detención («si el agente lleva > 5 minutos ejecutándose, detenlo»).
- Un pequeño servicio vigila y aplica.
Para sistemas que ejecutan muchos agentes simultáneamente, esto es esencial.
Patrón 12: Puntos de control con supervisión humana
Para agentes de alto riesgo, incluye puntos de revisión con humanos. El agente ejecuta hasta un punto de revisión, luego espera la aprobación humana.
Puntos de revisión típicos:
- Antes de acciones destructivas.
- Después de una decisión que el agente no puede revertir.
- En hitos importantes de una tarea larga.
- Cuando la confianza disminuye.
No se trata de desconfianza, sino de detectar los errores cuando todavía son baratos de corregir.
Un flujo de trabajo práctico: el agente hace trabajo preparatorio de forma autónoma, presenta un resumen y acciones propuestas, el humano aprueba, el agente ejecuta. El humano está en el bucle para decisiones, no en el bucle para cada paso.
Ejemplo práctico: un agente de investigación de larga duración
Para ilustrar, los patrones aplicados a un agente real:
Tarea: Investigar a un competidor y producir un resumen.
Trabajo estimado: 10-30 búsquedas web, 20-50 lecturas de páginas, síntesis en un resumen de 1000 palabras.
Patrones aplicados:
-
Presupuesto de pasos: 60 pasos totales.
-
Presupuesto de tokens: 300K tokens (contexto + acciones). Si se excede, resume los hallazgos actuales y continúa.
-
Presupuesto de costes: €2 por ejecución. Si se excede, detén y devuelve un resumen parcial.
-
Presupuesto de tiempo: 5 minutos de reloj real.
-
Seguimiento del progreso: En cada paso, el agente actualiza un “registro de hallazgos” con nueva información. Si pasan 3 pasos sin nuevos hallazgos, escapa.
-
Detección de repeticiones: Si la misma consulta de búsqueda se ejecuta dos veces con resultados similares, fuerza un enfoque diferente.
-
Puntos de reflexión: Cada 10 pasos, el agente reflexiona sobre el progreso y el trabajo restante.
-
Anclaje del objetivo: El objetivo original del resumen se menciona al principio de cada mensaje del sistema.
-
Salidas de emergencia: “Tengo suficiente información” o “no puedo encontrar información suficiente” terminan al agente de forma elegante.
-
Monitor externo: Un observador independiente mata agentes que exceden presupuestos.
Resultado: Tiempo medio de ejecución 3 minutos. Coste medio €0.40. Tasa de fallos —bucles o tiempos de espera— < 1%. Los resúmenes tienen 700-1200 palabras, están fundamentados en hechos y constituyen puntos de partida útiles.
Sin estos patrones: ejecuciones ocasionales de 30 minutos, costes ocasionales de €20+, sesiones bloqueadas ocasionales. Los patrones reducen drásticamente la cola.
Detección en producción
Incluso con patrones, algunos problemas se filtran. Detecta:
Alertas sobre agentes de larga duración. Cualquier agente con una duración > 2x la mediana activa una alerta.
Alertas de picos de costes. Coste por agente o acumulado por encima del umbral.
Alertas sobre patrones repetitivos. Patrones de llamadas a herramientas que sugieren bucles.
Revisión diaria de trazas de larga duración. Un humano revisa las 10 trazas más largas del día. Detecta problemas que las evaluaciones pasan por alto.
Métricas agregadas: tasa de bucles a lo largo del tiempo. Permite detectar cambios en el modelo o el prompt que aumenten su frecuencia.
Un panel útil: distribución de duraciones de ejecución de agentes. La cola te dice sobre la incidencia de bucles.
Errores comunes
Algunos patrones que vemos repetidamente:
Error 1: Sin presupuesto de pasos. “Lo añadiremos si lo necesitamos.” Luego el agente entra en bucle a las 3 de la madrugada y deseas que lo hubieras añadido. Añádelo desde el primer día.
Error 2: Presupuestos demasiado altos. «100 pasos serán suficientes», pero un bucle los consume. Fija el presupuesto en 2-3x la mediana, no en el peor caso.
Error 3: Sin monitor externo. Confianza en que el agente se detenga solo. A veces no lo hace. El monitor externo es esencial en producción.
Error 4: Detectar bucles sin analizarlos. El monitor detiene la ejecución y el equipo sigue adelante; la semana siguiente se repite. Realiza siempre un análisis posterior: qué lo provocó, qué cambió y cómo puede evitarse esa clase de fallo.
Error 5: Reflexión agresiva en tareas simples. Forzar reflexión cada 5 pasos en una tarea de 5 pasos es sobrecarga sin beneficio. Calibra según la complejidad de la tarea.
Error 6: Objetivos perdidos en contextos largos. Un objetivo mencionado una vez en el paso 1 no sobrevive al paso 50. Reancla regularmente.
Error 7: Confianza en autoinformes del agente sobre el progreso. Los agentes dirán que están avanzando cuando no lo están. Verifica externamente cuando sea posible.
Error 8: Permitir que los agentes se llamen a sí mismos recursivamente. “Descomponer esta tarea en subagentes” puede producir un número exponencial de agentes. Si lo permites, presupuesta estrictamente.
Cuando los bucles son aceptables
No todos los bucles son malos. Algunas tareas legítimamente requieren muchas iteraciones:
- Refinamiento iterativo del código (escribir, probar, corregir, repetir).
- Investigación de múltiples pasos con ramificaciones.
- Tareas de optimización (intentar variaciones, evaluar, refinar).
Para estas, los bucles son el trabajo, no un fallo. Los patrones cambian:
- Presupuestos generosos de pasos (50-200 pasos).
- Enfoque explícito en “iteración”, no en “bucle”.
- Seguimiento de mejora de calidad — cada iteración debe mejorar una métrica.
- Detenerse firmemente cuando la mejora se estanque.
El principio consiste en distinguir entre «trabajo iterativo planificado» y «bucles no planificados», y aplicar los patrones adecuados a cada caso.
La lista de verificación de producción
Los agentes que entran en bucles infinitos son predecibles, comunes y prevenibles. Los patrones son bien conocidos: presupuestos de pasos, seguimiento del progreso, detección de repeticiones, reflexión, anclaje del objetivo, salidas de emergencia, protecciones de herramientas, monitorización externo.
No son mejoras opcionales. Marcan la diferencia entre agentes que pueden desplegarse y agentes que generan facturas inesperadas de cuatro cifras.
Para cualquier agente de producción, la lista de verificación:
- Presupuesto máximo de pasos.
- Presupuesto máximo de tokens.
- Presupuesto máximo de costes.
- Presupuesto máximo de tiempo.
- Detección de llamadas repetidas.
- Seguimiento del progreso.
- Reflexión periódica.
- Anclaje del objetivo.
- Varios puntos de salida de emergencia.
- Monitor externo con capacidad de detener la ejecución.
Cada control es sencillo de implementar. Juntos marcan la diferencia entre «es peligroso dejar este agente en ejecución» y «este agente es fiable en producción».
Construye los patrones. Prueba. El riesgo de cola que eliminas vale el trabajo muchas veces.
