Agent Drift: cuando los agentes de IA pierden el foco

El problema

Desde fuera, todo parece estable. El monitoreo no grita, no hay incidentes visibles, y la tasa de éxito (success rate) casi no cambia.

Pero en las métricas de run se ve un desvío: hace una semana este agente cerraba la tarea en 2-3 pasos, y tras una pequeña actualización de prompt y versión de modelo, ahora necesita 7-9.

El sistema no se cayó.

Simplemente se fue desviando poco a poco.

Analogía: imagina una balanza de tienda que se equivoca solo 1-2 gramos cada día. El primer día casi no se nota. En un mes, el error ya impacta toda la caja. Con un agente pasa lo mismo: un drift pequeño en cada run crea una pérdida grande a escala.

Por qué pasa

Los agentes LLM son sistemas estocásticos. Un cambio pequeño en modelo, prompt o datos de entrada puede cambiar el orden de pasos. Incluso una diferencia mínima en el reasoning loop se acumula y termina en drift.

En producción, el drift suele avanzar en silencio:

1. cambia el modelo, prompt, tool output o datos de retrieval;
2. el agente formalmente sigue completando tareas;
3. pero hace pasos distintos y consume más recursos;
4. sin comparación con baseline, parece que "todo está bien".

El problema no es un cambio puntual. El problema es la falta de control de releases que detecte desviaciones del baseline temprano.

Qué fallos aparecen con más frecuencia

Para mantenerlo práctico, en producción normalmente se separan cuatro tipos de drift.

Drift de modelo

Después de cambiar versión de LLM, el agente empieza a ordenar pasos de otra forma: "revisa una vez más" más seguido, termina más tarde o elige otro tool.

Causa típica: se actualizó versión de modelo sin comparación contra baseline en un conjunto golden de tareas.

Drift en prompt

Un ajuste pequeño en el system prompt cambia prioridades del agente: se vuelve "demasiado cauteloso" o "demasiado activo".

Causa típica: se cambió el prompt como texto, no como código de producción con test y canary.

Drift de contratos de herramientas

Un tool devuelve un campo nuevo, otro formato de error o un array vacío en lugar de null. El agente lo interpreta distinto y cambia su ciclo de decisión.

En producción esto pasa fácilmente a fallo de herramienta o tool spam.

Drift en retrieval y contexto

Se actualizó el índice de conocimiento: se agregaron documentos, cambió ranking, aumentaron chunks irrelevantes en el context window. El agente formalmente funciona, pero toma hechos incorrectos más seguido.

Por síntomas esto suele parecerse a context poisoning.

Cómo detectar estos problemas

El drift se ve mejor no en una sola métrica, sino en desviaciones frente al baseline.

Cómo distinguir drift de un cambio realmente útil

No todo cambio de comportamiento es malo. A veces la versión nueva sí es mejor. La pregunta clave: si mejoró la calidad sin costo desproporcionado.

Normal si:

• la calidad subió y tokens_per_task + latency_p95 casi no cambiaron;
• el comportamiento nuevo es estable en tareas golden;
• canary no muestra subida de timeout y max_steps_reached.

Peligroso si:

• success rate se parece, pero costo y latencia suben;
• los stop reasons se mueven hacia límites;
• el agente usa herramientas más veces sin ganar precisión.

Cómo detener estos fallos

En la práctica se ve así:

1. haces un cambio (candidate);
2. en CI, el Drift gate ejecuta tests y compara candidate con baseline en quality/tokens/tool calls/latency/stop reasons;
3. si se violan umbrales, se bloquea release o se hace rollback;
4. si los umbrales están bien, el cambio va a canary y luego a rollout completo.

baseline
   ↓
candidate evaluation
   ↓
threshold gate
   ↓
canary
   ↓
production

Barrera mínima contra drift en runtime CI:

from dataclasses import dataclass


@dataclass(frozen=True)
class Thresholds:
    max_tool_calls_delta: int = 2
    max_tokens_delta_pct: float = 0.30
    max_latency_delta_pct: float = 0.30
    allow_stop_reason_change: bool = False


def violates_thresholds(baseline: dict, candidate: dict, t: Thresholds) -> list[str]:
    errors: list[str] = []

    if candidate["tool_calls"] > baseline["tool_calls"] + t.max_tool_calls_delta:
        errors.append("tool_calls_delta_exceeded")

    if candidate["tokens"] > baseline["tokens"] * (1 + t.max_tokens_delta_pct):
        errors.append("tokens_delta_exceeded")

    if candidate["latency_ms"] > baseline["latency_ms"] * (1 + t.max_latency_delta_pct):
        errors.append("latency_delta_exceeded")

    if (not t.allow_stop_reason_change) and candidate["stop_reason"] != baseline["stop_reason"]:
        errors.append("stop_reason_changed")

    return errors

Esta barrera no hace magia. Solo evita que se publique una regresión más lenta y más cara disfrazada de release "exitoso".

Dónde se implementa en la arquitectura

El control de drift normalmente se reparte en dos capas.

Agent Runtime registra señales de drift durante ejecución: stop_reason_distribution, steps_per_task, tokens_per_task. Sin estas métricas, threshold gate no tiene con qué comparar.

Tool Execution Layer es fuente de parte del drift: un cambio en formato de tool output, una retry policy nueva o un contrato de error distinto cambia silenciosamente el comportamiento del agente. Aquí conviene versionar contratos de herramientas.

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.

FAQ

Q: ¿Drift siempre significa que el modelo es peor?
A: No. Drift significa que cambió el comportamiento. Es malo cuando el cambio no está medido ni controlado.

Q: ¿Puedo detectar drift solo con success rate?
A: No. Success rate suele llegar tarde. Antes se mueven tool_calls, tokens, latencia y stop reasons.

Q: ¿Canary es necesario para cambios pequeños de prompt?
A: En sistemas high-traffic sí. Incluso una frase en el prompt puede cambiar la elección de acciones del agente.

Q: ¿Qué hacer si hay drift pero la calidad mejora un poco?
A: Calcula unit economics: costo por run exitoso en baseline y candidate. Si mejora calidad y el nuevo costo se mantiene en presupuesto, haz ship y fija nuevo baseline.

Agent drift casi nunca se ve como una caída. Es una regresión lenta que solo se ve comparando con baseline. Por eso, en producción no basta con mejores modelos: hace falta control estricto de release.

Páginas relacionadas

Para cerrar mejor el drift en producción, revisa:

• Por qué fallan los agentes de IA - mapa general de fallos típicos en producción.
• Budget explosion - cómo el drift de comportamiento infla costos en silencio.
• Tool spam - cómo controlar el crecimiento de llamadas innecesarias.
• Context poisoning - cómo problemas de contexto se disfrazan de decisiones "raras" del agente.
• Agent Runtime - dónde colocar release-gates, límites y stop reasons.
• Tool Execution Layer - dónde mantener validación, retries y control de llamadas.