7 min read
Last updated:
Your LLM agent did not crash. It returned a confident, well-formed answer. The user accepted it. Three weeks later, an internal audit shows the agent quietly drifted into recommending a deprecated SKU for two thousand customers. No exception fired. No latency alarm. No log line marked itself suspicious. This is the new failure mode, and most engineering organizations are running production AI systems without the observability primitives required to detect it.
Traditional APM treats success as a 200 response within an SLO. Agents break that assumption. A response can be syntactically valid, semantically wrong, and economically catastrophic in the same call. If you are running agents in customer-facing or revenue-impacting paths in 2026, your monitoring stack needs an explicit redesign, not a dashboard added to the existing one.
The four silent failure classes you must instrument
Before you choose a tool, name the failures. Every observability decision below traces back to one of these four classes. If your team cannot articulate which class a recent incident belonged to, you do not have observability, you have logs.
Hallucination drift
The model fabricates a fact, citation, identifier, or capability. The output looks plausible. Detection requires either a ground-truth oracle (rare in production) or a downstream signal (user thumbs-down, support ticket, refund). By the time the downstream signal arrives, you have shipped the error to a population. Mitigation is not a single check; it is a layered claim-extraction and verification pass that runs as part of the response pipeline, not a daily batch job.
Tool-call drift
The agent picks the wrong tool, calls the right tool with malformed arguments, or loops over a tool without converging. Tool-call drift is the most underinstrumented failure in 2026 production stacks because most teams trace the LLM call but not the tool-graph traversal. The fix is to record every tool decision as a span attribute (tool name, arguments hash, retry index, parent decision id) and to alert on tool-loop depth above a threshold per task class.
Cost spike
A change in upstream context length, a regression in a retrieval system that returns oversized documents, or an agent that adopts a new chain-of-thought pattern can multiply per-request token cost by ten in a single deploy. Cost is observable in cents per request and tokens per request; treat both as first-class SLO metrics with budgets per route, not as a finance line item reviewed monthly.
Latency outliers
P99 latency in agent systems is dominated by retries, tool calls, and reasoning loops, not by the base model call. A naive p50 or p95 dashboard will hide the p99.5 user who waited forty-five seconds while the agent re-planned three times. Latency alarms must be split by stage (planning, retrieval, tool, generation) and by route, not aggregated across all agent traffic.
Instrumentation patterns that actually work in 2026
Three approaches dominate the market. Each has a real cost and a real benefit. The choice depends on the maturity of your platform team and how much vendor lock-in you can stomach.
The first option is a managed agent-tracing vendor: LangSmith, LangFuse, Helicone, Arize Phoenix. These products give you a usable trace UI, prompt-version diffing, and a feedback capture flow within an afternoon of integration. The cost is per-trace pricing that becomes painful past a few million daily spans, plus a partial picture: they see the calls you instrument, not the broader request lifecycle.
The second option is OpenTelemetry with the GenAI semantic conventions that stabilized in late 2025. You emit spans with the standard gen_ai.* attributes (model name, token counts, finish reason, tool calls) and route them to whatever backend you already pay for: Datadog, Honeycomb, Grafana Tempo, Tempo plus Loki. This is the right answer for any organization that already invested in OpenTelemetry and has a platform team capable of maintaining it. You get unified traces across your full stack with one trace id from edge to LLM to tool to database.
The third option is a hybrid: managed vendor for prompt and evaluation workflows, OTel for production telemetry. This is what most large engineering organizations land on by their second year. The vendor handles the iteration loop where product and ML engineers live; OTel handles the SRE loop where on-call engineers live.
Semantic alerts vs operational alerts
Operational alerts are the ones your SRE team already understands: error rate, latency, saturation. Port these to your agent infrastructure with route-level granularity and you have covered roughly forty percent of the surface area. The remaining sixty percent requires semantic alerts, which most teams have never built.
A semantic alert fires on the meaning of the agent output, not its operational properties. Examples that pay for themselves within a quarter:
- Refusal rate above baseline by route, indicating either a prompt regression or a model behavior change after a vendor update
- Citation density below threshold for any response in a regulated workflow (legal, medical, financial)
- Tool-call entropy above threshold per session, indicating the agent is exploring rather than executing
- Output-length distribution shift versus a rolling seven-day baseline, often the first signal of a context-window regression
- PII pattern matches in agent outputs that should never contain PII
- Cost per resolved task above the unit-economics threshold for the product
Semantic alerts require a small evaluation service that runs lightweight classifiers over a sampled stream of agent outputs. Do not run them on the hot path; sample one to ten percent of traffic and aggregate. The point is not to block bad responses in real time, the point is to know within fifteen minutes when the population behavior shifts.
Incident review for AI systems
The standard postmortem template was written for systems where root cause is a code path or a config value. For agent failures, root cause is often a triple: a prompt version, a model version, and a context distribution. Your template needs three fields the original did not.
First, the prompt and model lineage at the time of the incident. If you cannot reconstruct the exact system prompt, tool list, and model snapshot a request used, you cannot debug it. Pin model versions explicitly; never call a moving alias like claude-sonnet-latest in production.
Second, a representative sample of inputs that triggered the failure, anonymized and stored. Aggregate metrics tell you something is wrong; sample inputs let you reproduce. Build a one-click “export incident sample” pipeline now, before you need it at three in the morning.
Third, an explicit blast-radius estimate. How many users saw the bad output, how many took action on it, how many of those actions are reversible. For a deterministic system, blast radius is often known from logs. For agents, you have to estimate from sampled traces and customer support volume; this estimation is itself a capability you build over time.
Recommendation
If you are running fewer than ten thousand agent calls per day and you are early in your AI maturity, start with a managed vendor (LangFuse if open-source matters, LangSmith if you live in the LangChain ecosystem, Arize Phoenix if you want both). Get traces, prompt diffing, and a feedback loop in a week. Defer the OTel project.
If you are running more than a hundred thousand agent calls per day or you have regulated workloads, build the OTel layer first, then layer the vendor on top for the iteration loop. Treat the agent stack as a first-class production service with on-call rotation, runbooks, and the same blast-radius hygiene you would apply to a payments system.
In every case, define your four silent failure classes for your specific product, write at least three semantic alerts, and pin model versions. Those three steps separate teams that learn about agent failures from their dashboards from teams that learn about them from their customers.
When this applies and when it does not
This framework applies when an LLM is in a path where wrong outputs have customer or revenue impact. Internal-only agents, prototypes behind a feature flag for fewer than a hundred users, and one-shot summarization of low-stakes content do not need this stack. Adding it prematurely will slow your iteration speed without buying you reliability you can measure.
It does not apply to RAG systems where the LLM is a thin formatting layer over deterministic retrieval. There, classical search-quality metrics (recall at k, MRR, click-through) carry most of the signal, and agent observability is overkill. Build it when your system gains tool use, multi-turn planning, or autonomous decision authority over external resources. Until then, your existing monitoring is probably enough.