Introducción

En producción, los sistemas de agentes fallan de formas sorprendentes. El LLM alucina el nombre de una herramienta. Una API devuelve un 500. El usuario pregunta algo fuera del alcance del agente. Un bucle se ejecuta indefinidamente porque el modelo sigue llamando a la misma herramienta con la misma entrada. Nada de esto es teórico: cualquier agente que se ejecute durante un tiempo prolongado los experimentará.

Esta lección cubre los patrones que hacen que los agentes sean fiables: reintentos con backoff, validación de entradas antes de las llamadas a herramientas, validación de salidas tras las respuestas del modelo, circuit breakers para detener bucles descontrolados y fallbacks elegantes cuando el modelo produce algo que no puedes parsear. El objetivo no es hacer al agente perfecto, sino hacer que los fallos sean predecibles, registrados y recuperables.

Validación de entradas antes de la ejecución de herramientas

Antes de pasar cualquier cosa a una herramienta externa, valídala. El modo de fallo más común es que el agente genere un argumento de una herramienta que parece sintácticamente correcto pero es semánticamente absurdo: una fecha en el año 9999, un ID de usuario que no existe, una consulta SQL con una cláusula ausente.

def get_user_orders(user_id: str, date_from: str, date_to: str) -> dict:
    # Validate user_id is numeric and exists
    if not user_id.isdigit() or not user_exists(user_id):
        return {"error": "invalid_user_id", "message": f"User {user_id} not found"}

    # Validate date format
    try:
        from datetime import datetime
        datetime.strptime(date_from, "%Y-%m-%d")
        datetime.strptime(date_to, "%Y-%m-%d")
    except ValueError:
        return {"error": "invalid_date", "message": "Dates must be YYYY-MM-DD"}

    # Validate date range
    if date_from > date_to:
        return {"error": "invalid_range", "message": "date_from must be before date_to"}

    # Now safe to call the actual tool
    return query_orders(user_id, date_from, date_to)

Cuando la validación falla, devuelve un objeto de error estructurado, no una excepción. El agente lo lee y decide qué hacer a continuación: pedir aclaración al usuario, probar un enfoque diferente o rendirse de forma controlada.

Reintentos, backoff y circuit breakers

Los fallos transitorios (timeouts de red, errores 503, límites de tasa) merecen reintentos. Pero los reintentos ingenuos empeoran las cosas: si el servicio downstream está sobrecargado, golpearlo con más fuerza solo lo mantiene caído.

import time
import random

def call_with_retry(fn, max_attempts=3, base_delay=1.0):
    for attempt in range(max_attempts):
        try:
            result = fn()
            if attempt > 0:
                log_recovery(attempt)  # Log that retry succeeded
            return result
        except RetryableError as e:
            if attempt == max_attempts - 1:
                raise
            delay = base_delay * (2 ** attempt) + random.uniform(0, 0.5)
            log_retry_attempt(attempt, e, delay)
            time.sleep(delay)

El backoff exponencial con jitter reparte el tráfico de reintentos para que no sincronices a todos tus agentes reintentando en el mismo instante. Solo reintenta en errores clasificados como transitorios; nunca reintentes en un 400 Bad Request, porque la misma entrada producirá el mismo fallo cada vez.

Los circuit breakers van un paso más allá: si una herramienta ha fallado N veces seguidas, deja de llamarla durante un período de cooldown y falla rápido. Esto te protege de agentes que quedan atrapados en un bucle contra un servicio caído.

class CircuitBreaker:
    def __init__(self, failure_threshold=5, cooldown_seconds=60):
        self.failures = 0
        self.threshold = failure_threshold
        self.cooldown = cooldown_seconds
        self.open_until = 0

    def call(self, fn):
        if time.time() < self.open_until:
            raise CircuitOpenError(f"Circuit open until {self.open_until}")
        try:
            result = fn()
            self.failures = 0
            return result
        except Exception:
            self.failures += 1
            if self.failures >= self.threshold:
                self.open_until = time.time() + self.cooldown
            raise

Validación de la salida del modelo y manejo de bucles

El modelo a veces producirá una salida que no coincide con el esquema esperado: un blob JSON al que le falta un campo obligatorio, una llamada a herramienta con argumentos del tipo incorrecto, una "llamada a función" que en realidad es una oración en lenguaje natural alucinada. Necesitas una capa que detecte esto.

def parse_agent_response(raw: str) -> AgentAction:
    try:
        parsed = json.loads(raw)
    except json.JSONDecodeError:
        return AgentAction.recover("Model returned non-JSON output")

    if "tool" not in parsed or "arguments" not in parsed:
        return AgentAction.recover("Missing tool or arguments field")

    if parsed["tool"] not in ALLOWED_TOOLS:
        return AgentAction.reject(f"Model tried to call unknown tool: {parsed['tool']}")

    return AgentAction.execute(parsed["tool"], parsed["arguments"])

La detección de bucles es igualmente importante. Haz seguimiento de los últimos N pares (herramienta, argumentos). Si el mismo par se repite más de M veces, aborta el agente y muestra un error al usuario, algo como "Parece que estoy atascado repitiendo el mismo paso". Sin esta protección, un modelo confundido puede quemar miles de tokens llamando a la misma herramienta sin salida.

Degradación controlada y errores面向 usuario

Cuando el agente no puede completar una tarea, la respuesta al usuario debe ser específica y accionable. "Ocurrió un error" es inútil. "No pude recuperar tus pedidos porque el servicio de pedidos no está disponible temporalmente. Inténtalo de nuevo en un minuto, o puedo mostrarte el resumen de tu cuenta" le dice al usuario qué ocurrió y le ofrece una alternativa.

Construye una cadena de fallback: si la herramienta principal falla, prueba una herramienta secundaria más simple (por ejemplo, datos en caché en lugar de datos en vivo, o una llamada diferente a un LLM con un alcance menor). Si todo falla, devuelve una respuesta final que explique la limitación con honestidad. Nunca inventes datos en silencio para cubrir una llamada a herramienta faltante: los usuarios lo detectan y la confianza se pierde.

Resumen

Los agentes fiables se construyen a partir de capas de validación, reintentos y manejo elegante de fallos. Valida las entradas antes de las herramientas, reintenta los errores transitorios con backoff exponencial y jitter, usa circuit breakers para detener bucles descontrolados, valida la salida del modelo contra un esquema estricto, detecta acciones repetidas para evitar bucles infinitos y siempre da al usuario una respuesta específica y honesta cuando algo sale mal. Los patrones de esta lección se aplican tanto si construyes con LangChain, orquestación personalizada o cualquier otro framework de agentes: el framework puede gestionar parte de esto por ti, pero aun así debes comprender lo que ocurre por debajo.