DEV Community: Saurav Bhattacharya

Your AI Agent Drifted Last Night and You Didn't Notice

Saurav Bhattacharya — Sat, 06 Jun 2026 01:02:25 +0000

The Silent Failure Mode

Your agent passed every test in CI. It ran fine in staging. Then it quietly started returning subtly wrong answers in production at 2 AM, and nobody noticed until a customer complained three days later.

This is agent drift — the gradual degradation of agent output quality without any hard failures. No exceptions thrown. No schema violations. Just slowly worsening responses that slip past your monitoring.

Here's my thesis: the hardest production failures aren't crashes — they're quality degradation that happens between your eval checkpoints. You need continuous runtime detection, not just pre-deployment testing.

Three Drift Vectors

After running production agents 24/7, I've identified three distinct drift patterns:

1. Context Staleness

Your agent retrieves documents, knowledge bases, or API responses as context. That context decays:

interface StalenessDetector {
  source: string;
  maxAgeMs: number;
  check: (context: RetrievedContext) => StalenessResult;
}

const stalenessChecks: StalenessDetector[] = [
  {
    source: 'knowledge-base',
    maxAgeMs: 24 * 60 * 60 * 1000, // 24 hours
    check: (ctx) => {
      const age = Date.now() - ctx.lastIndexedAt;
      const staleChunks = ctx.chunks.filter(c => 
        Date.now() - c.sourceLastModified > 7 * 24 * 60 * 60 * 1000
      );
      return {
        stale: staleChunks.length / ctx.chunks.length > 0.3,
        staleFraction: staleChunks.length / ctx.chunks.length,
        oldestChunkAge: Math.max(...ctx.chunks.map(c => Date.now() - c.sourceLastModified)),
        recommendation: staleChunks.length > 0 
          ? `${staleChunks.length} chunks older than 7 days` 
          : 'fresh'
      };
    }
  },
  {
    source: 'api-response-cache',
    maxAgeMs: 60 * 60 * 1000, // 1 hour
    check: (ctx) => {
      const cached = ctx.apiResponses.filter(r => r.fromCache);
      const expired = cached.filter(r => Date.now() - r.cachedAt > 60 * 60 * 1000);
      return {
        stale: expired.length > 0,
        staleFraction: expired.length / Math.max(cached.length, 1),
        recommendation: expired.length > 0
          ? `${expired.length} cached API responses expired`
          : 'fresh'
      };
    }
  }
];

The insidious part: stale context doesn't cause errors. Your agent happily generates confident answers based on outdated information. The output looks fine — it's just wrong.

2. Behavioral Drift

The agent's response patterns shift over time. Maybe the underlying model got a silent update. Maybe prompt injection attempts are subtly reshaping behavior. Maybe token distributions are shifting due to accumulated conversation context.

interface DriftBaseline {
  dimension: string;
  expectedDistribution: { mean: number; stddev: number };
  windowSize: number;
}

class BehavioralDriftDetector {
  private baselines: Map<string, DriftBaseline> = new Map();
  private observations: Map<string, number[]> = new Map();

  observe(dimension: string, value: number): DriftAlert | null {
    const baseline = this.baselines.get(dimension);
    if (!baseline) return null;

    const window = this.observations.get(dimension) || [];
    window.push(value);
    if (window.length > baseline.windowSize) window.shift();
    this.observations.set(dimension, window);

    if (window.length < baseline.windowSize * 0.5) return null;

    const currentMean = window.reduce((a, b) => a + b, 0) / window.length;
    const zScore = Math.abs(currentMean - baseline.expectedDistribution.mean) 
      / baseline.expectedDistribution.stddev;

    if (zScore > 2.5) {
      return {
        dimension,
        severity: zScore > 4 ? 'critical' : 'warning',
        currentMean,
        expectedMean: baseline.expectedDistribution.mean,
        zScore,
        message: `${dimension} drifted ${zScore.toFixed(1)} sigma from baseline`
      };
    }
    return null;
  }
}

The key insight: you're not evaluating individual outputs. You're evaluating the distribution of outputs over time. A single long response means nothing. A gradual increase in average response length across 100 runs? That's signal.

3. Hallucination Creep

Hallucination rates aren't constant. They vary with input complexity, context quality, and model state. The dangerous pattern: hallucination rate slowly climbs from 2% to 8% over a week, crossing your acceptable threshold without ever triggering a single hard failure.

interface HallucinationCanary {
  name: string;
  detect: (output: AgentOutput, groundTruth: GroundTruth) => HallucinationSignal;
}

const canaries: HallucinationCanary[] = [
  {
    name: 'entity-grounding',
    detect: (output, truth) => {
      const claimedEntities = extractEntities(output.raw);
      const groundedEntities = extractEntities(truth.sourceDocuments);
      const ungrounded = claimedEntities.filter(e => 
        !groundedEntities.some(g => semanticMatch(e, g, 0.85))
      );
      return {
        hallucinated: ungrounded.length > 0,
        ungroundedEntities: ungrounded,
        groundingRate: 1 - (ungrounded.length / Math.max(claimedEntities.length, 1))
      };
    }
  },
  {
    name: 'numeric-consistency',
    detect: (output, truth) => {
      const claimedNumbers = extractNumericClaims(output.raw);
      const sourceNumbers = extractNumericClaims(truth.sourceDocuments);
      const inconsistent = claimedNumbers.filter(claim =>
        !sourceNumbers.some(src => 
          src.entity === claim.entity && 
          Math.abs(src.value - claim.value) / src.value < 0.05
        )
      );
      return {
        hallucinated: inconsistent.length > 0,
        inconsistentClaims: inconsistent,
        consistencyRate: 1 - (inconsistent.length / Math.max(claimedNumbers.length, 1))
      };
    }
  }
];

The Runtime Monitoring Loop

Detection is one half. The other half is what you do about it. Here's the runtime loop I've converged on:

async function monitorAgentRun(run: AgentRun): Promise<MonitorResult> {
  // 1. Pre-execution: Check context freshness
  const stalenessResults = await checkStaleness(run.context);
  if (stalenessResults.some(r => r.stale)) {
    await refreshStaleContext(run, stalenessResults);
  }

  // 2. Post-execution: Lightweight drift check on every run
  const driftAlerts = trackDimensions(run.output, {
    responseLength: estimateTokens(run.output.raw),
    toolCalls: run.output.toolCallCount,
    latency: run.durationMs,
    confidenceProxy: run.output.metadata?.confidence ?? null
  });

  // 3. Sampled: Hallucination canary (expensive, run on 10% sample)
  let hallucinationResult = null;
  if (Math.random() < 0.1 && run.groundTruthAvailable) {
    hallucinationResult = await runCanaries(run.output, run.groundTruth);
  }

  // 4. Alert on threshold breach
  if (driftAlerts.some(a => a.severity === 'critical')) {
    await alertOncall('agent-drift-critical', driftAlerts);
  }

  return { stalenessResults, driftAlerts, hallucinationResult };
}

Notice the layering: staleness checks are pre-execution (you can fix stale context before the agent runs). Drift detection is post-execution and cheap (runs on every invocation). Hallucination canaries are expensive and sampled.

What I Got Wrong Initially

Three mistakes I made building this:

1. Alerting on individual outliers. An agent producing one long response isn't drift. I burned weeks chasing false positives before switching to windowed statistical detection.

2. Not versioning baselines. When you intentionally change agent behavior (new prompt, new model), your baselines need to reset. Otherwise every intentional improvement triggers drift alerts.

3. Treating hallucination as binary. "The agent hallucinated" is useless. What did it hallucinate? Entities? Numbers? URLs? The category determines the fix.

The Production Checklist

If you're running agents in production without drift monitoring, start here:

Track three dimensions minimum: response length, latency, and tool call count. These are cheap proxies that catch gross behavioral changes.
Set baselines from your last 7 days of production data, not from test runs. Test distributions don't match production.
Alert on 2.5 sigma deviations over rolling windows, not individual outliers.
Check context freshness before execution, not after. Stale context is the one drift type you can prevent rather than detect.
Sample hallucination checks at 5-10% unless you have specific high-risk outputs that warrant 100% coverage.

The Uncomfortable Truth

Most teams discover drift through customer complaints. By the time a user says "your AI gave me wrong information," you've likely been serving degraded responses for days or weeks.

The gap between "my agent works" and "my agent works reliably" is entirely about what happens between your evaluation checkpoints. Continuous monitoring isn't optional — it's the difference between running a demo and running a product.

How are you detecting drift in your production agents? Or are you still finding out from users? I'm curious what signals have been most useful for early detection.

Deterministic Checks vs Model-as-Judge: A Tiered Approach to Agent Evaluation

Saurav Bhattacharya — Fri, 05 Jun 2026 23:39:39 +0000

The Core Problem

You shipped an AI agent. It works in demos. Then it runs 10,000 times in production, and you realize you have no idea which runs were good.

This is the agent evaluation problem, and most teams approach it backwards. They reach for model-as-judge ("ask GPT-4 if the output is good") because it feels natural. But this is like using a microscope when you needed a ruler first.

Here's my thesis: a tiered evaluation architecture—deterministic checks first, model-as-judge only where necessary—catches more failures, costs less, and gives you actionable signal faster.

The Three Tiers

After building eval infrastructure for production agents, I've landed on a three-tier model:

Tier 1: Deterministic Assertions (catches ~60% of failures)

These are the boring checks. They're also the most valuable.

interface DeterministicCheck {
  name: string;
  check: (output: AgentOutput) => { pass: boolean; reason?: string };
}

const structuralChecks: DeterministicCheck[] = [
  {
    name: 'valid-json-output',
    check: (output) => {
      try {
        JSON.parse(output.raw);
        return { pass: true };
      } catch (e) {
        return { pass: false, reason: `Invalid JSON: ${e.message}` };
      }
    }
  },
  {
    name: 'no-hallucinated-urls',
    check: (output) => {
      const urls = extractUrls(output.raw);
      const knownDomains = getAllowedDomains(output.context);
      const unknown = urls.filter(u => !knownDomains.includes(new URL(u).hostname));
      return {
        pass: unknown.length === 0,
        reason: unknown.length > 0 ? `Unknown domains: ${unknown.join(', ')}` : undefined
      };
    }
  },
  {
    name: 'required-fields-present',
    check: (output) => {
      const parsed = JSON.parse(output.raw);
      const missing = output.schema.required.filter(f => !(f in parsed));
      return {
        pass: missing.length === 0,
        reason: missing.length > 0 ? `Missing: ${missing.join(', ')}` : undefined
      };
    }
  }
];

Why start here? Three reasons:

Latency: These run in <1ms. You can evaluate every single agent run, not a sample.
Determinism: No flaky results. A JSON parse error is a JSON parse error.
Debuggability: When a check fails, you know exactly what broke.

Tier 2: Heuristic Scoring (catches ~20% more)

These are computed properties that don't require an LLM but capture quality signals:

interface HeuristicScore {
  name: string;
  score: (output: AgentOutput) => number; // 0-1
  threshold: number;
}

const heuristics: HeuristicScore[] = [
  {
    name: 'response-conciseness',
    score: (output) => {
      const tokenCount = estimateTokens(output.raw);
      const expectedRange = output.context.expectedTokenRange;
      if (tokenCount < expectedRange[0]) return tokenCount / expectedRange[0];
      if (tokenCount > expectedRange[1]) return expectedRange[1] / tokenCount;
      return 1.0;
    },
    threshold: 0.7
  },
  {
    name: 'context-utilization',
    score: (output) => {
      const contextEntities = extractEntities(output.context.provided);
      const outputEntities = extractEntities(output.raw);
      const used = contextEntities.filter(e => outputEntities.includes(e));
      return used.length / Math.max(contextEntities.length, 1);
    },
    threshold: 0.3
  }
];

These aren't pass/fail—they're continuous scores. Track them over time. When the distribution shifts, something changed.

Tier 3: Model-as-Judge (the remaining ~20%)

Only now—after deterministic and heuristic checks pass—do you invoke an LLM judge:

async function modelJudge(output: AgentOutput, criteria: JudgeCriteria): Promise<Judgment> {
  const prompt = `
You are evaluating an AI agent's output for: ${criteria.dimension}

Context provided to agent:
${output.context.summary}

Agent output:
${output.raw}

Score 1-5 on ${criteria.dimension}. Respond with JSON:
{"score": <int>, "reasoning": "<one sentence>"}
`;

  const result = await judge.complete(prompt, { temperature: 0 });
  return JSON.parse(result);
}

Critical design decisions for model-as-judge:

Use it for subjective dimensions only: tone, helpfulness, nuance. Not for things you can check deterministically.
Temperature 0, always: You want reproducibility, not creativity.
Structured output: Force JSON responses. Parse failures become Tier 1 check failures on your judge itself.
Judge the judge: Run your model-as-judge on known-good and known-bad examples. Track its accuracy. It drifts.

Why Order Matters

The tiered approach isn't just about efficiency. It's about failure attribution.

When a Tier 1 check fails, you know the agent produced structurally invalid output. You can fix the prompt, the schema enforcement, or the output parser. The fix is concrete.

When a model-as-judge scores something 2/5, you know... something is subjectively wrong. Maybe. Unless the judge is having a bad day. The signal is useful in aggregate but dangerous for individual decisions.

async function evaluateRun(output: AgentOutput): Promise<EvalResult> {
  // Tier 1: Fast, deterministic. Gate everything else.
  const tier1Results = structuralChecks.map(c => c.check(output));
  if (tier1Results.some(r => !r.pass)) {
    return { tier: 1, pass: false, results: tier1Results, skipHigherTiers: true };
  }

  // Tier 2: Heuristic scores. Flag but don't block.
  const tier2Results = heuristics.map(h => ({ 
    name: h.name, 
    score: h.score(output), 
    threshold: h.threshold 
  }));

  // Tier 3: Only if Tier 1 passes and context warrants it.
  const tier3Results = output.context.requiresSubjectiveEval 
    ? await runModelJudge(output)
    : null;

  return { tier: 3, pass: true, results: { tier1Results, tier2Results, tier3Results } };
}

The Economics

Let's make it concrete. Say you run 10,000 agent invocations per day:

Approach	Cost/day	Latency added	Signal quality
Model-as-judge on everything	~$50-150	2-5s per eval	High but noisy
Tiered (deterministic first)	~$5-15	<10ms for 80%	Higher and cleaner

The tiered approach is 10x cheaper because you only invoke the expensive judge on the ~20% of runs that pass structural checks AND require subjective evaluation.

What This Looks Like in Practice

In agent-eval, we implement this as a pipeline where checks are composable:

const pipeline = createEvalPipeline([
  tier('deterministic', [jsonValid, schemaConforms, noHallucinatedLinks]),
  tier('heuristic', [conciseness, contextUsage, formatAdherence]),
  tier('judge', [helpfulness, technicalAccuracy], { sampleRate: 0.2 })
]);

// Run on every agent output
const result = await pipeline.evaluate(agentOutput);

Note the sampleRate: 0.2 on the judge tier. Even within Tier 3, you don't need to judge everything. Sample, aggregate, alert on distribution shifts.

The Takeaway

If you're building agent evaluation, resist the temptation to start with model-as-judge. Start with the dumbest possible checks:

Did the agent return valid JSON?
Are all required fields present?
Are the URLs real?
Is the response length reasonable?

These catch the majority of production failures. They're fast, cheap, deterministic, and debuggable. Save the expensive subjective evaluation for where it actually matters.

What's your experience with agent evaluation in production? Are you running model-as-judge on everything, or have you found ways to tier your checks? I'd love to hear what patterns have worked.