How to monitor AI agents in production

TL;DR

Monitoring AI agents in production is different from monitoring traditional services. Agents don't crash when they fail — they keep working, just expensively, wrongly, or in loops. The signals are different, the dashboards look different, and most teams set up the wrong things first.

Five things actually matter:

• 1. Per-call cost and latency — the basic vital signs
• 2. Token usage patterns — input/output ratios, model distribution, caching efficiency
• 3. Behavioral patterns — call sequences, tool usage, session shapes
• 4. Outcome signals — accepted vs discarded outputs, retry rates
• 5. Anomaly detection — what's different about today vs baseline

Most teams over-invest in #1 and #2 (the easy ones) and under-invest in #3, #4, and #5 (the ones that catch actual problems). This post walks through how to set up each layer.

Why "monitoring AI agents" isn't the same as "monitoring services"

Traditional services tell you when they fail. Errors get thrown, error rates spike, alerts fire, you fix it. The system is designed to surface failure loudly.

Agents fail differently. They don't crash — they keep working. Every individual call looks identical to a successful one. The only signal that something is wrong is aggregate behavior over time — too many calls, climbing token counts, an anomaly in pattern rather than an anomaly in output.

A few examples of the failure modes you're actually monitoring for:

• An agent stuck in a retry loop, burning tokens without making progress
• A customer triggering a feature in a way that costs 30x normal
• A model routing bug sending requests to Opus when Sonnet would suffice
• A prompt change that doubled token usage without anyone noticing
• An agent that's working perfectly but at a rate that will blow the monthly budget by week two

None of these throw errors. None of them break a dashboard. All of them are real incidents that hit teams running AI in production today.

That's why monitoring AI agents requires a different approach than monitoring web services or background jobs. Same observability primitives, different signals to watch for.

Layer 1 — Per-call cost and latency

The vital signs. Every LLM call should emit metrics for cost, latency, model, and outcome. This is the easiest layer to set up and the most table-stakes — every team has it within their first quarter of running AI in production.

Wrap your LLM client to emit metrics on every call:

async def call_llm(prompt, model, customer_id, feature):
    start = time.time()
    response = await anthropic_client.messages.create(
        model=model,
        max_tokens=1024,
        messages=[{"role": "user", "content": prompt}],
    )

    metrics.emit("llm_call", {
        "model": model,
        "customer_id": customer_id,
        "feature": feature,
        "input_tokens": response.usage.input_tokens,
        "output_tokens": response.usage.output_tokens,
        "cost_usd": calculate_cost(model, response.usage),
        "duration_ms": (time.time() - start) * 1000,
        "success": True,
    })
    return response

Push the metrics into whatever observability stack you already use — Prometheus, Datadog, Honeycomb, OpenTelemetry. Build dashboards for:

• Cost per hour, per day, per week
• p50/p95/p99 latency by model
• Token throughput (in/out)
• Error rate (the rare cases where the API itself fails)

What this layer catches: vendor outages, latency degradation, sudden cost spikes from infrastructure changes.

What this layer misses: literally every interesting failure mode. The dashboards will look healthy while a retry loop is burning $1,000 a day, because each individual call looks fine.

Layer 2 — Token usage patterns

A step up in sophistication. Now you're not just tracking "how much did we spend" but "what does our usage look like."

Three patterns worth watching:

Input/output token ratio. Most agentic workloads have predictable ratios — a code review agent might output 1 token for every 50 it reads. When that ratio shifts dramatically (say, suddenly 1:10), something in the prompt structure or model behavior has changed. Often a prompt engineering bug.

Model distribution. If your application uses multiple models, track how usage splits. Unexpected shifts (Opus suddenly handling 80% of calls when it should be Sonnet) often indicate a routing bug. The Datadog State of AI Engineering 2026 report found median tokens per request grew 2.5x in a year, largely from incorrect model selection.

Cache hit rate. If you're using prompt caching (and you should be), track the percentage of cache-eligible calls actually hitting cache. The Datadog 2026 report found that only 28% of cache-eligible calls actually use caching across the industry. That's a lot of money on the table. A monitoring dashboard that shows your cache hit rate makes this visible.

Sample queries to set up in Grafana/Datadog:

# Cache hit rate by feature
sum(rate(llm_cache_hit_total[5m])) by (feature)
  / sum(rate(llm_call_total[5m])) by (feature)

# Model distribution by feature
sum(rate(llm_call_total[1h])) by (feature, model)

# Token input/output ratio
sum(rate(llm_input_tokens_total[1h])) by (feature)
  / sum(rate(llm_output_tokens_total[1h])) by (feature)

What this layer catches: prompt engineering regressions, model routing bugs, caching misconfiguration, gradual cost drift.

What this layer misses: behavior at the session level — patterns across multiple calls in sequence.

Layer 3 — Behavioral patterns

This is where most monitoring setups fall down. The signals here are about how agents are working, not what they're costing.

Three patterns to monitor:

Call sequence shape. Healthy agent sessions usually follow a predictable pattern — a planning call, a few tool calls, a synthesis call, done. Unhealthy sessions have shapes — 47 tool calls in a row, the same operation repeated 12 times, a session that never reaches a final state.

The simplest way to track this: emit a session_complete event with metadata about what happened during the session. Number of calls, tools used, total cost, duration, whether it reached a terminal state.

metrics.emit("session_complete", {
    "session_id": session.id,
    "agent_name": session.agent,
    "total_calls": session.call_count,
    "total_cost_usd": session.cost,
    "duration_ms": session.duration_ms,
    "tools_used": list(session.tools),
    "reached_terminal_state": session.completed,
    "abandoned": session.abandoned,
})

Tool call frequency. Track which tools your agents call and how often. A sudden spike in Bash tool calls or Edit tool calls often indicates an agent stuck doing something the wrong way. Healthy agents use a balanced mix of tools; unhealthy ones use one tool obsessively.

Session abandonment rate. Sessions that start but never complete are often the most expensive failures. The agent ran, consumed tokens, then either timed out or got stuck. Track the percentage of sessions that reach a successful terminal state vs those that don't.

What this layer catches: retry loops, stuck agents, tool misuse, prompt engineering regressions that don't show up as cost spikes.

What this layer misses: quality and outcome questions — is the agent actually being useful?

Layer 4 — Outcome signals

The hardest layer to set up and the most valuable when you do.

The question this layer answers: of all the agent runs we paid for, how many produced output that was actually useful?

Three signals worth capturing:

Accept/reject events. If your application has a way for users to accept or reject AI output (a "keep this answer" button, an "apply this edit" action), emit an event for both. The ratio of accepted vs rejected outputs is one of the highest-signal metrics you can track.

Retry rates. If a user retries an AI action — asks the same question again, regenerates the response, or undoes an applied change — that's a signal the first output was wrong. Track per-feature and per-customer retry rates over time.

Time-to-acceptance. How long after an AI output appears does the user accept or reject it? Fast accepts usually mean the output was right. Long delays often mean the user is reading, thinking, deciding whether to keep it. Very long delays often mean abandonment.

This is genuinely hard to build because it requires instrumentation in your application layer, not just your LLM call layer. But teams that do this well end up with the most defensible AI products — they can answer "is our AI actually useful?" with real data instead of vibes.

What this layer catches: quality regressions, prompt changes that degraded usefulness, model changes that hurt customers, features that aren't worth the cost.

Honest note: this layer is where the gap between monitoring and operational intelligence lives. Tracking cost-per-accepted-output instead of just cost-per-call is what separates teams who understand their AI economics from teams who don't.

Layer 5 — Anomaly detection across all layers

The five layers above are dashboards. This layer is the thing that pages you when a dashboard would show something wrong if you happened to be looking at it.

For each metric in layers 1-4, set up baseline expectations and alerts on deviation:

• Cost per hour > 3x rolling 7-day average → page on-call
• Cache hit rate < 50% of normal → investigate
• Session abandonment rate > 2x baseline → investigate
• Reject rate > 1.5x baseline on any feature → investigate

The tools that handle this well: Datadog, Honeycomb, Grafana with Prometheus AlertManager, OpenTelemetry-compatible vendors. For laptop-level monitoring (Claude Code, Cursor, Codex), the gap remains real — most production observability tools don't see developer-laptop AI usage.

One common mistake: alerting on absolute thresholds instead of deviations from baseline. "Alert when cost exceeds $X/hour" eventually fires during legitimate growth and becomes noise. "Alert when cost exceeds 3x rolling average" stays useful as the team scales.

A word on AIWatcher

The pattern in this post — five layers of monitoring, anomaly detection, outcome signals — works whether you build it yourself or use a tool. If you're building it yourself, the post above is the playbook.

If you'd rather skip the build, AIWatcher is the operational layer that handles this for you. Layers 1-3 work out of the box with a one-line SDK. Layer 5 (anomaly detection) is built in. Layer 4 (outcome signals) requires light application instrumentation but we provide the schema and the dashboards, including per-customer cost attribution. Same dashboard also covers your team's internal AI tool usage (Claude Code, Cursor, Codex CLI on developer machines) if you want both surfaces in one view — but that's a bonus for teams that have both surfaces, not the reason to pick AIWatcher for the production-monitoring problem you're solving today.

AIWatcher is in design partner mode in 2026 with mid-market AI-native SaaS companies. Request access →

Closing

Monitoring AI agents in production is mostly about acknowledging that they fail differently than traditional services. They don't crash. They don't throw errors. They just keep working — sometimes correctly, sometimes expensively, sometimes uselessly.

The teams that get this right aren't doing anything magical. They've layered their monitoring around the actual failure modes — cost, patterns, behavior, outcomes — instead of relying on the failure modes traditional observability was built to catch.

Start with layer 1, ship layer 2 within the first quarter, push for layers 3 and 4 within six months. You don't need all five layers from day one. You do need to know which ones you're missing.

Danny is the founder of AIWatcher, the operational layer for AI agents.