Los 4 Modos de Fallo de los Agentes de IA en Producción (y Cómo Mitigarlos)

La promesa y la realidad

La promesa de los agentes es seductora: le das a un LLM un objetivo y un puñado de herramientas, y lo dejas iterar en un loop hasta que decide que ha terminado. Lee, razona, llama a una herramienta, observa el resultado, vuelve a razonar. Suena a magia.

La realidad en producción es menos romántica. Ese loop es exactamente donde se quema el dinero y donde el estado se corrompe. Y lo más incómodo: los fallos que vas a ver no son problemas de calidad del modelo. Un modelo más grande no los arregla. Son problemas del bucle de control — el mismo tipo de problema que llevas resolviendo décadas con watchdogs, circuit breakers y máquinas de estado, solo que aplicado a un dominio nuevo.

Cuatro modos de fallo se repiten en cualquier runtime agéntico, da igual el framework. Si construyes sobre agentes, los vas a encontrar. La buena noticia es que cada uno tiene una mitigación conocida y barata. Este post es el mapa.

Anatomía de un turno

Antes de los fallos, el vocabulario. Un turno es un ciclo: una invocación al LLM más la ejecución de las herramientas que pida. Una tarea son muchos turnos encadenados hasta una condición de salida. El agente “vive” dentro de ese loop de turnos.

Todo lo que puede salir mal con un loop cae en tres categorías: no termina nunca, termina sin progresar, o termina mal. Los cuatro modos de fallo son variantes concretas de esas tres. Vamos uno a uno.

Fallo 1: el loop que no termina

Síntoma. El agente llama a la misma herramienta con los mismos argumentos una y otra vez. O alterna entre dos acciones en un ciclo A-B-A-B-A. O toca el mismo recurso cuarenta veces sin que nada cambie. La factura de tokens sube en línea recta y no sale ningún resultado.

Por qué pasa. El LLM no tiene una memoria fiable de “esto ya lo intenté y no funcionó”. Un resultado de herramienta ligeramente ambiguo le hace reintentar lo mismo. Un estado que no entiende lo deja dando vueltas. No es que el modelo sea tonto: es que el loop no tiene frenos.

La mitigación. Un detector de loops que inspeccione el historial reciente de llamadas a herramientas. Tres patrones cubren la mayoría de casos:

// Señales de loop sobre el historial reciente de tool-calls.
function detectLoop(history: ToolCall[]): LoopSignal | null {
  // Las tools de solo lectura (read, list, status) se EXCLUYEN:
  // repetirlas es legítimo, no es un loop.
  const actions = history.filter((c) => !c.tool.isReadOnly);

  // 1. Llamadas idénticas consecutivas (misma tool + mismos args)
  if (lastNAreIdentical(actions, 3)) {
    return { kind: "identical", advice: "abort" };
  }

  // 2. El mismo objetivo tocado N veces sin un solo cambio de estado
  if (sameTargetWithoutWrite(actions, 4)) {
    return { kind: "target-repetition", advice: "abort" };
  }

  // 3. Ciclo alternante A-B-A-B-A
  if (isAlternatingCycle(actions, 5)) {
    return { kind: "alternating", advice: "abort" };
  }

  return null;
}

El parámetro que importa. El umbral N. Demasiado bajo y cancelas trabajo válido (un agente que reintenta dos veces algo razonable). Demasiado alto y pagas miles de tokens antes de cortar. No hay un número universal: depende de la clase de herramienta. Empieza conservador, mide, y ajusta con los datos reales de tus loops.

Fallo 2: el turno que se queda colgado

Síntoma. Un turno empieza y no termina nunca. La llamada al LLM se queda esperando, una herramienta bloquea en una operación de red sin timeout, un subproceso muere y el padre sigue esperando una respuesta que no va a llegar. El “slot” del agente queda ocupado para siempre. En un sistema con varios agentes en paralelo, un puñado de turnos colgados te consume toda la capacidad.

Por qué pasa. Timeouts del proveedor del LLM, I/O sin cota, deadlocks, un proceso hijo que el sistema operativo mató por memoria y del que nadie se enteró. Cualquier cosa que pueda bloquear, en producción, acaba bloqueando.

La mitigación. El patrón clásico del proceso zombi, aplicado a turnos: heartbeats más un watchdog. Cada turno emite un latido (un timestamp) mientras está vivo. Un proceso en segundo plano escanea periódicamente y, si encuentra un turno cuyo último latido es más viejo que el umbral, lo da por muerto, libera el slot y opcionalmente reencola la tarea.

Fallo 3: el turno que no hace nada

Síntoma. El agente produce un párrafo precioso explicando lo que va a hacer, o directamente declara “la tarea está completa” — pero llama a cero herramientas. No ha pasado nada. El estado está intacto. Es especialmente frecuente en roles de coordinación y con modelos que se deslizan hacia el modo conversación.

Por qué pasa. Los modelos instruct están entrenados para ser elocuentes. Si no les fuerzas la llamada a función, te devuelven prosa. Y hay un fallo más sutil y más peligroso: un modelo que cree que ha terminado pero no ha tocado nada.

La mitigación. Una puerta de ejecución (execution gate). Para los turnos que se supone que deben actuar, exige al menos una llamada a herramienta. Cero llamadas en un turno que debía ejecutar algo equivale a turno fallido — no aceptes la narración como resultado. Los roles genuinamente conversacionales o de coordinación quedan exentos.

Pero la lección de fondo es mayor que un gate. Es la regla más importante de todo el documento:

En la práctica esto significa que la transición a “completado” la decide el runtime tras comprobar efectos reales, no el agente diciendo que ya está. Cuesta más de implementar. Es la diferencia entre una demo y producción.

Fallo 4: el error mal clasificado

Síntoma. Algo falla. Un sistema ingenuo hace una de tres cosas, todas malas: reintenta para siempre, se rinde al primer error, o trata todos los errores igual. Pero un parpadeo de red transitorio y un “no tienes permiso” exigen respuestas opuestas. Reintentar un error de permisos es quemar tokens; rendirse ante un 5xx transitorio es abandonar trabajo que habría salido bien al segundo intento.

Por qué pasa. Los errores son heterogéneos y el código tiende a tratarlos como una masa uniforme — un catch genérico que no distingue.

La mitigación. Una taxonomía explícita de errores conectada a una tabla de políticas. Cada tipo de error tiene una fila: cuántos reintentos, qué backoff, y qué acción terminal cuando se agotan.

Tipo de error	Reintentos	Backoff	Acción al agotar
Transitorio (red, 5xx)	3	exponencial	escalar a supervisor
Rate limit (429)	5	exponencial + jitter	escalar a supervisor
Entrada inválida (4xx)	0	—	corregir la entrada / abortar
Permisos / auth	0	—	escalar a un humano
Contrato / lógica	1	—	abortar
Desconocido	2	exponencial	escalar a un humano

Dos propiedades hacen que esta tabla funcione. Primera: es exhaustiva — todo error cae en alguna fila, y los desconocidos tienen una política conservadora por defecto (pocos reintentos y luego escalar). Segunda, y crítica: la acción al agotar nunca es “marcar como completado en silencio”. Cuando se agotan los intentos, escalas o abortas. Jamás finges éxito. Es el mismo principio del Fallo 3, visto desde el otro lado.

El hilo conductor

Para cuando llevas un rato peleándote con esto, ves que los cuatro fallos son la misma historia contada cuatro veces: el agente no es la autoridad sobre su propio progreso.

• El loop infinito es el agente creyendo que avanza cuando no avanza.
• El turno colgado es el agente sin dar señales de vida y el sistema sin enterarse.
• El turno vacío es el agente afirmando acción donde no la hubo.
• El error mal clasificado es el agente (o un catch perezoso) malinterpretando qué significa un fallo.

En los cuatro, la solución es la misma de fondo: el runtime —no el modelo— es quien decide cuándo parar, qué cuenta como vivo, qué cuenta como acción y qué significa un error. Trata al agente como un trabajador capaz pero poco fiable dentro de un arnés fiable. El arnés es donde vive la robustez de producción.

Observabilidad: ver el fallo antes de pagarlo

No puedes mitigar lo que no ves. Los cuatro modos de fallo son invisibles hasta que llega la factura o el ticket de soporte — salvo que instrumentes el loop.

La recomendación concreta: adopta las convenciones semánticas de OpenTelemetry para GenAI. Un span por turno con atributos gen_ai.* (sistema, modelo, tokens de entrada y salida, motivo de finalización), y spans hijo por cada llamada a herramienta. Sobre eso, unas pocas métricas: turnos ejecutados, tokens consumidos, latencia del LLM, ejecuciones de herramientas, reintentos y escalados.

Con esa telemetría, los fallos dejan de ser invisibles:

• El loop infinito aparece como un pico en la tasa de tokens por minuto.
• El turno colgado es un span que se abre y nunca se cierra.
• El turno vacío es un turno cuyo span no tiene ningún hijo de tipo tool-call.
• El error mal clasificado es un pico de reintentos sobre el mismo tipo de error.

La checklist

Si te llevas una sola cosa, que sea esta lista. Es el mínimo viable para llevar agentes a producción sin sustos:

• Detector de loops (idénticos / alternantes / mismo objetivo), eximiendo herramientas de solo lectura.
• Heartbeat más watchdog para turnos colgados, y timeout explícito en toda llamada externa.
• Execution gate: los turnos de acción exigen al menos una llamada a herramienta; la narración nunca cuenta como éxito.
• Taxonomía de errores con tabla de políticas; la acción al agotar es escalar o abortar, nunca fingir que se completó.
• Nunca auto-Done: la finalización se decide por efectos verificables, no por la palabra del agente.
• Instrumentación OTel GenAI más una alerta sobre la tasa de tokens.

Preguntas frecuentes

Conclusión

Ninguno de estos cuatro fallos se arregla con un modelo mejor, porque ninguno es un fallo de inteligencia: son fallos de bucle de control. Y eso, en realidad, son buenas noticias. Quiere decir que no estás ante un problema nuevo e irresoluble, sino ante problemas viejos y bien entendidos —watchdogs, circuit breakers, máquinas de estado, taxonomías de error— reaplicados a un dominio que parece nuevo pero no lo es tanto.

El agente aporta la inteligencia. Tú aportas el arnés. La fiabilidad de producción no vive en el prompt: vive en el código que rodea al loop.