All resources Build vs Buy & Tooling

Observability for Agentic AI

Observability for agents is different from observability for services. The four pillars and what's specific.

TL;DR

Observability for AI agents has four pillars different from traditional observability:

  1. Trace-level visibility — every step in a multi-step agent run.
  2. Tool call tracking — what external actions were taken.
  3. Cost and latency — per request, per agent, per use case.
  4. Quality signals — eval scores in production, drift detection.

Standard APM tools (Datadog, New Relic) provide some; AI-specific platforms (Langfuse, Braintrust, LangSmith) provide the rest. Most enterprises need both.


Observability for agents is different from observability for services. The four pillars and what’s specific.

The “we have observability” framing for traditional services doesn’t transfer cleanly to AI agents. Agent observability needs trace-level detail, tool call tracking, cost and quality dimensions. Companies that try to use traditional APM alone for AI hit visibility gaps. This piece is the framework for what AI observability requires.

What’s different about agent observability

Three differences from traditional service observability.

1. Each agent run has multi-step internal structure. Tool calls, model invocations, retrievals. Need trace-level visibility, not just request/response.

2. Tool calls are the actions. For autonomous agents, the tool calls are how the agent affects the world. Observability needs to capture them specifically.

3. Quality is a continuous concern. Service observability tracks errors and latency; agent observability also tracks output quality.

The four pillars

Pillar 1: Trace-level visibility

Every agent run produces a trace: the sequence of internal steps from input to output.

Specifically:

  • Each LLM call with prompt and response.
  • Each tool call with arguments and result.
  • Each retrieval with query and results.
  • Timing for each step.
  • Error context for failures.

Why it matters: when an agent goes wrong, you need to see the trace to diagnose. Without it, debugging is guesswork.

Pillar 2: Tool call tracking

Specific monitoring of tool calls:

  • Tool call frequency by tool.
  • Success/failure rate per tool.
  • Cost (where applicable) per tool.
  • Latency per tool.
  • Anomaly detection on tool call patterns.

Why it matters: tools are the action surface. Anomalous tool call patterns indicate either bugs or potential security issues.

Pillar 3: Cost and latency

Per-request, per-agent, per-use-case visibility:

  • Token cost per request, with model attribution.
  • Latency at p50, p95, p99.
  • Tool call cost (where applicable).
  • Cost trending over time.

Why it matters: AI costs can grow rapidly with usage; visibility prevents bill shock and identifies optimization opportunities.

Pillar 4: Quality signals

Production quality monitoring:

  • Eval scores on production traffic samples.
  • Drift detection against baseline.
  • User feedback (thumbs up/down, complaints).
  • Output characteristics (length, structure, language).

Why it matters: quality drift is silent. Without continuous monitoring, you find out from customer complaints.

Build vs buy

For each pillar:

PillarDefault
Trace-level visibilityBuy (Langfuse, Braintrust, LangSmith)
Tool call trackingBuy (often integrated with above)
Cost and latencyBuy (AI-specific) + Buy (general APM for serving infrastructure)
Quality signalsBuy (eval platform)

Most enterprises end up with two systems: AI-specific observability for the four pillars + general APM for the serving infrastructure. Some organizations use general APM with AI extensions (Datadog has been adding AI capability); the AI-specific platforms are typically deeper.

What gets in the way

Three failure modes.

1. Insufficient instrumentation in the agent code. If agents don’t emit trace data, observability is hollow. Every agent should emit traces from day one.

2. Sampling that misses the issues. Sampling for cost reasons can miss the rare failures that matter. Better to sample more heavily for high-stakes deployments.

3. Dashboards without operational ownership. Building dashboards is one thing; having someone watch them and act is another. AI ops capacity matters.

What to do this quarter

  1. Audit your agent observability. Do you have all four pillars?
  2. Pick the largest gap. Usually quality signals or trace-level visibility.
  3. Buy the AI observability platform if you don’t have one.
  4. Establish operational ownership. Someone responsible for watching the dashboards and acting.

Counter: aren’t traditional APM tools adding AI features?

Yes, slowly. Datadog, New Relic, Splunk are adding AI-specific capabilities. The depth varies; for now, AI-specific platforms are typically better for the four pillars. Expect convergence over 2026–2027.

FAQ

How much data should we retain? Trace data: 30–90 days for active investigation. Aggregated metrics: years. Audit-grade records (separate from observability): per regulatory needs.

What about sensitive data in traces? Redact or hash before logging. Don’t store PII or regulated data in trace logs without encryption and access controls.

Can we build observability in-house? For specialized needs: maybe. For the standard four pillars: vendor solutions are mature enough that build doesn’t pay off for most enterprises.

How does this interact with eval platform? Often the same vendor (Braintrust, Langfuse, LangSmith provide both). Quality signals are eval running in production.

What about open-source observability? OpenTelemetry-based instrumentation is increasingly common. AI observability standards (OpenLLMetry, etc.) are emerging. Vendor solutions can ingest OpenTelemetry traces.


Working with JAIN on AI observability? We help executive teams design and ship agent observability that prevents production surprises. Book a 30-minute call.

Related reading:

Want to talk through this for your team?

30 minutes, no slides. We'll work the specific call your company is facing.