Alerting Without Crying Wolf: SRE Strategies for Detecting Agent Drift Before It Becomes an Incident

The framing that the agentic loop itself is a small fraction of the production engineering problem is not rhetorical — it's a practical guide for where to instrument. Tool call logs, credential usage patterns, retry rates against downstream APIs, and queue depth in your async processor are all earlier signals of drift than anything the LLM itself will surface. If you're running TypeScript async processors on SQS and your agents dispatch tool calls through a controlled interface, you already have the integration points to capture this data; the gap is usually that nobody defined the baselines or wired them to alert thresholds. Source: [Stop giving your agents database credentials] — CrewAI Blog (https://blog.crewai.com/stop-giving-your-agents-database-credentials/)

AIThe shift the industry is making — from treating observability as a post-launch concern to treating it as a design constraint — means platform teams need to define 'normal' for each agent pipeline at build time, not after the first production incident. A per-task behavioral fingerprint (expected tool calls, token range, latency band, downstream service hit pattern) acts as a drift signature you can alert against without needing to interpret LLM outputs directly.

// TypeScript: Per-task behavioral fingerprint capture at tool dispatch
type TaskFingerprint = {
  taskType: string;
  toolCallCount: number;
  totalTokensUsed: number;
  completionLatencyMs: number;
  downstreamServices: string[];
};

async function recordTaskFingerprint(
  taskId: string,
  fingerprint: TaskFingerprint,
  baselineStore: FingerprintStore
): Promise<DriftSignal | null> {
  const baseline = await baselineStore.getBaseline(fingerprint.taskType);
  if (!baseline) return null;

  const drifts: string[] = [];
  if (fingerprint.toolCallCount > baseline.toolCallCount.p99) {
    drifts.push(`tool_call_spike: ${fingerprint.toolCallCount} > p99(${baseline.toolCallCount.p99})`);
  }
  if (fingerprint.totalTokensUsed > baseline.totalTokensUsed.p95 * 1.5) {
    drifts.push(`token_budget_creep: ${fingerprint.totalTokensUsed}`);
  }

  return drifts.length > 0 ? { taskId, taskType: fingerprint.taskType, signals: drifts } : null;
}

The architectural move here is treating the credential relay as an active observability point, not just a security control. Every token issuance is a logged event with task context, agent identity, and target resource — which means your alerting system can watch for agents making requests to resources outside their declared scope, or issuing unusually high request volumes for a given task type. This is structurally similar to how a service mesh handles mTLS identity and policy enforcement, except the principal is an agent session rather than a service instance. Source: [Why Code Verification Matters More Than Ever in the Age of AI] — ByteByteGo Blog (https://blog.bytebytego.com/p/why-code-verification-matters-more)

The ability to kill a hijacked agent session as a live process — rather than revoking a static credential that might already be cached in ten places — is a meaningful operational improvement. It maps well to the SRE concept of a blast radius reduction: you're not just stopping the current bad action, you're preventing the agent from replaying the credential in any future context window it might encounter.

// TypeScript: Relay middleware that logs and monitors agent credential usage
interface AgentTokenRequest {
  agentId: string;
  taskType: string;
  declaredScope: string[];
}

async function issueAgentToken(
  req: AgentTokenRequest,
  policyEngine: PolicyEngine,
  alertBus: AlertBus
): Promise<ScopedToken> {
  const policy = await policyEngine.evaluate(req.taskType, req.declaredScope);
  if (!policy.approved) throw new Error(`Scope denied for taskType: ${req.taskType}`);

  const token = await policyEngine.mintToken({
    subject: req.agentId,
    scope: policy.grantedScope,
    ttlSeconds: 300,
    allowedHosts: policy.allowedHosts,
  });

  await alertBus.emit('agent.token.issued', {
    agentId: req.agentId,
    taskType: req.taskType,
    grantedScope: policy.grantedScope,
    issuedAt: Date.now(),
  });

  return token;
}

The Grafana Alloy production scaling work makes a point that resonates directly with agentic platforms: you need an independent monitoring path for your telemetry gateway itself — something that doesn't route through the system under stress. In an agentic context, this is even more critical because drift conditions are correlated with volume spikes; a buggy planning loop that's re-invoking tools at 10x the normal rate will simultaneously degrade your ability to see it happening if your observability pipeline shares capacity with your workload pipeline. The engineering discipline here is pre-production load testing at realistic agent concurrency levels, with synthetic agents designed to simulate drift conditions (tool call storms, token budget exhaustion, repeated retries). Source: [How to scale Alloy as a central telemetry gateway] — Grafana Blog (https://grafana.com/blog/how-to-scale-alloy-as-a-central-telemetry-gateway-capacity-planning-load-testing-and-production-lessons/)

AIFor a PostgreSQL-backed platform, this extends to your per-phase provenance logging table as well — if every agent step writes a log row, a runaway agent producing 50x the normal step count will hammer your write throughput. Partitioning provenance tables by task type and agent session with aggressive TTL-based pruning is the structural answer; capping writes per session with a circuit-breaker is the operational one.

// TypeScript: Per-session write cap with circuit-breaker for provenance logging
const SESSION_STEP_LIMIT = 500; // alert at 80%, hard stop at 100%

async function logAgentStep(
  sessionId: string,
  step: AgentStepRecord,
  db: Pool,
  alertBus: AlertBus
): Promise<void> {
  const stepCount = await db.query<{ count: string }>(
    'SELECT COUNT(*) FROM agent_provenance WHERE session_id = $1',
    [sessionId]
  );
  const current = parseInt(stepCount.rows[0].count, 10);

  if (current >= SESSION_STEP_LIMIT) {
    await alertBus.emit('agent.step.circuit_open', { sessionId, stepCount: current });
    throw new Error(`Session ${sessionId} exceeded step limit — pipeline halted for review`);
  }
  if (current >= SESSION_STEP_LIMIT * 0.8) {
    await alertBus.emit('agent.step.approaching_limit', { sessionId, stepCount: current });
  }

  await db.query(
    'INSERT INTO agent_provenance (session_id, task_type, step_data, created_at) VALUES ($1, $2, $3, NOW())',
    [sessionId, step.taskType, JSON.stringify(step)]
  );
}

Ezra Klein's observation about the OpenAI/Hugging Face agents — that not one of thousands of agents ever attempted to check in with a human — points to an architectural gap that's easy to rationalize away during development. The human-in-the-loop design gets added as an explicit request surface (the agent 'asks' for help), but the implicit circuit-breaker path — where anomalous behavior automatically routes to human review without the agent's cooperation — is often missing. In a production agentic pipeline, that second path is the one that matters for drift containment, because a drifting agent isn't going to self-report. Source: [Fragments: August 24] — Martin Fowler Blog (https://martinfowler.com/fragments/2026-08-24.html)

AIThe practical implementation for a platform team is a tiered review queue: low-severity drift signals (slightly elevated tool call counts, minor latency exceedance) get logged for async batch review; high-severity signals (scope violations, session step circuit-breakers, downstream error cascades) get routed to synchronous human review with automatic pipeline pause. The key design constraint is that the queue must have a defined SLA and a defined maximum depth — otherwise it becomes a pressure-relief valve that silently discards the signals your governance model depends on.

// TypeScript: Tiered human review queue with depth enforcement
type DriftSeverity = 'low' | 'high';

const QUEUE_MAX_DEPTH = 200;
const QUEUE_SLA_MINUTES = 30;

async function routeToHumanReview(
  signal: DriftSignal,
  severity: DriftSeverity,
  reviewQueue: ReviewQueue,
  pipeline: AgentPipeline
): Promise<void> {
  if (severity === 'high') {
    await pipeline.pause(signal.sessionId);
    await reviewQueue.enqueueSync({
      signal,
      sessionId: signal.sessionId,
      pausedAt: Date.now(),
      slaDeadline: Date.now() + QUEUE_SLA_MINUTES * 60_000,
    });
    return;
  }

  const depth = await reviewQueue.asyncDepth();
  if (depth >= QUEUE_MAX_DEPTH) {
    // Treat overflow as high-severity — don't silently discard
    await routeToHumanReview(signal, 'high', reviewQueue, pipeline);
    return;
  }

  await reviewQueue.enqueueAsync({ signal, sessionId: signal.sessionId, enqueuedAt: Date.now() });
}

The conceptual leap worth making here is that an agent orchestrator is itself a kind of control plane: it holds declared intent (what the agent is supposed to do), observes runtime behavior (what the agent is actually doing), and has the ability to intervene. The gap in most current implementations is that the reconciliation loop — the part that compares declared intent to observed behavior and triggers a response — is either absent or manually operated. HCP Terraform's AI-driven lifecycle management makes this loop explicit for infrastructure; the same pattern needs to be engineered deliberately into agentic platforms. Source: [HCP Terraform is the control plane for AI-driven infrastructure] — HashiCorp Blog (https://www.hashicorp.com/blog/hcp-terraform-is-the-control-plane-for-ai-driven-infrastructure/)

AIFor a platform team running agent pipelines in production, this means treating every significant change to agent configuration — prompt template updates, tool permission changes, model version bumps — as a deployment event with a corresponding drift baseline reset. Without resetting the baseline after a legitimate configuration change, your alerting system will fire false positives on every update, which is exactly how SRE teams get trained to ignore alerts. The discipline of 'declare, observe, reconcile' borrowed from infrastructure tooling is the right mental model for agent operational governance.

// TypeScript: Baseline reset on legitimate config change to suppress false positives
interface AgentConfigVersion {
  agentId: string;
  version: string;
  promptTemplateHash: string;
  toolPermissions: string[];
  modelVersion: string;
  effectiveAt: number;
}

async function onAgentConfigDeployed(
  newConfig: AgentConfigVersion,
  baselineStore: FingerprintStore,
  alertBus: AlertBus
): Promise<void> {
  // Suppress drift alerts for 1 warm-up window after config change
  await baselineStore.markInCooldown(newConfig.agentId, {
    cooldownUntil: newConfig.effectiveAt + 15 * 60_000, // 15-minute window
    reason: `Config deployed: v${newConfig.version}`,
  });

  // Schedule baseline recalculation after warm-up
  await baselineStore.scheduleRecalculation(newConfig.agentId, {
    after: newConfig.effectiveAt + 15 * 60_000,
    configVersion: newConfig.version,
  });

  await alertBus.emit('agent.config.deployed', {
    agentId: newConfig.agentId,
    version: newConfig.version,
    baselineResetScheduled: true,
  });
}

The gap between code that executes correctly in isolation and code that behaves reliably inside an agent pipeline is wider than in conventional systems, because agent tool calls happen in contexts (reasoning chains, accumulated state, partial results from prior steps) that are difficult to replicate in unit tests. AI-assisted development accelerates the production of tool implementations, but it also accelerates the production of implementations that encode implicit assumptions about call frequency, input format, or response structure that the agent's actual behavior will eventually violate. Source: [Why Code Verification Matters More Than Ever in the Age of AI] — ByteByteGo Blog (https://blog.bytebytego.com/p/why-code-verification-matters-more)

AIThe practical gate for a platform team is a verification checklist that runs at PR merge time for any change to the agent tool layer: Does this tool implementation enforce a maximum call count per session? Does it validate the shape of inputs against the expected schema before executing? Does it emit a structured log event that the drift detection system can consume? These aren't heavy process gates — they're the same kind of definition-of-done discipline that senior engineers already apply to REST API implementations, adapted for the specific failure modes of agent tool dispatch.

// TypeScript: Tool implementation template with built-in observability contracts
function createAgentTool<TInput, TOutput>(config: {
  name: string;
  maxCallsPerSession: number;
  inputSchema: ZodSchema<TInput>;
  execute: (input: TInput, context: ToolContext) => Promise<TOutput>;
}) {
  return async (rawInput: unknown, context: ToolContext): Promise<TOutput> => {
    // Enforce call count per session
    const callCount = await context.sessionState.incrementToolCall(config.name);
    if (callCount > config.maxCallsPerSession) {
      await context.alertBus.emit('tool.call.limit_exceeded', {
        tool: config.name,
        sessionId: context.sessionId,
        callCount,
      });
      throw new Error(`Tool ${config.name} exceeded per-session call limit`);
    }

    // Validate input shape before execution
    const input = config.inputSchema.parse(rawInput);

    // Emit structured step event for drift detection
    const start = Date.now();
    const result = await config.execute(input, context);
    await context.alertBus.emit('tool.call.completed', {
      tool: config.name,
      sessionId: context.sessionId,
      latencyMs: Date.now() - start,
      callCount,
    });

    return result;
  };
}

Lilian Weng's deep treatment of recursive self-improvement maps to a near-term engineering problem even in systems that aren't pursuing AGI: any pipeline that uses eval results to automatically tune prompts, adjust tool priorities, or modify retrieval configurations is operating a feedback loop that your drift detection system wasn't designed to track. The risk isn't runaway intelligence — it's that your alerting baselines become wrong without anyone noticing, because the system changed legitimately and the baseline wasn't updated. Source: [Harness Engineering for Self-Improvement] — Lilian Weng (https://lilianweng.github.io/posts/2026-07-04-harness/)

AIThe governance design here is straightforward but requires deliberate wiring: any automated modification to agent configuration or behavior must emit a versioned change event that flows through the same baseline reset pipeline as a human deployment. Without that, your SRE team is effectively monitoring against a specification that no longer matches the running system — which is how false negatives accumulate silently until a real incident surfaces them.

// TypeScript: Governed self-modification event with provenance logging
interface SelfModificationEvent {
  agentId: string;
  modificationSource: 'eval_feedback' | 'automated_tuning' | 'human_override';
  previousConfigHash: string;
  newConfigHash: string;
  evalMetrics: Record<string, number>;
  approvedBy: string | 'auto-approved'; // 'auto-approved' only if within policy bounds
  timestamp: number;
}

async function applyGovernedModification(
  agentId: string,
  candidate: ConfigCandidate,
  policy: ModificationPolicy,
  baselineStore: FingerprintStore,
  auditLog: AuditLogger
): Promise<void> {
  const withinPolicy = policy.evaluate(candidate);
  if (!withinPolicy) {
    await auditLog.write({ agentId, event: 'modification_rejected', candidate });
    throw new Error('Modification outside policy bounds — requires human review');
  }

  const event: SelfModificationEvent = {
    agentId,
    modificationSource: 'eval_feedback',
    previousConfigHash: candidate.previousHash,
    newConfigHash: candidate.newHash,
    evalMetrics: candidate.evalMetrics,
    approvedBy: 'auto-approved',
    timestamp: Date.now(),
  };

  await auditLog.write(event);
  await baselineStore.markInCooldown(agentId, { cooldownUntil: Date.now() + 15 * 60_000, reason: 'auto-modification applied' });
  await candidate.apply();
}