AI Agent Observability: How to Know Your Agents Are Actually Working
Tracing, evals, and guardrail monitoring — the tooling stack that keeps production AI agents honest and catches failures before users do.
You shipped the agent. It’s running. But is it working? Shipping an agent to production without observability isn’t confidence—it’s optimism. Agent observability is not LLM monitoring: multi-turn failures are invisible at the individual call level and only visible in full-session causal traces. Operators who treat tracing as a nice-to-have are flying blind on exactly the failures that erode user trust. Here’s the tooling layer that keeps production agents accountable.
Why Standard APM Won’t Save You
Traditional application monitoring was built for deterministic systems. Unlike traditional software with deterministic execution paths, AI agents employ large language models to plan, reason, and execute multi-step workflows autonomously—and this non-deterministic behavior creates unprecedented challenges for development teams.
The failure modes are categorically different. Most agent incidents stem from tool-call failures, context truncation, and runaway loops rather than model errors; standard APM tools cannot see these without agent-aware instrumentation. Your existing Datadog dashboards won’t tell you why an agent got stuck in a retry loop, over-consumed tokens on a single planning step, or handed off to a sub-agent that silently failed.
If you’re building on LangGraph Cloud or orchestrating tasks through n8n, you need a purpose-built layer on top—not a general metrics pipeline.
The Three Layers of Evaluation You Actually Need
Solid agent observability runs on three distinct eval layers that serve different purposes:
Unit evals on discrete steps, LLM-as-judge regression suites for subjective output quality, and continuous production trace sampling to catch real-world drift. Miss any one of these and you have gaps that will eventually become incidents.
Unit evals catch hard failures: did the tool call return the expected schema? Did the planning step produce a valid action? LLM-as-judge handles the softer, harder-to-quantify stuff—is this response accurate, grounded, on-topic? And production trace sampling is what closes the loop: risky production traces become evaluation cases for future CI, scheduled evals, and regression testing.
The key insight operators consistently miss is the feedback loop. Braintrust makes it easier to turn production failures into regression tests: when a user reports a bad response, teams can convert the trace directly into an evaluation case, which shortens the path from issue discovery to a test that prevents the same failure from shipping again.
Tracing: The Platform Landscape
The three platforms operators most commonly land on are LangSmith, Langfuse, and Arize Phoenix. They occupy genuinely different niches.
LangSmith is the natural home for teams already on LangChain or LangGraph. LangSmith is an observability and evaluation platform from the LangChain team that helps developers trace, debug, evaluate, and monitor LLM applications, with the strongest integration available for teams building on LangChain and LangGraph. Pricing: LangSmith Plus costs $39 per seat per month and includes 10K base traces per seat; the free plan includes 5K traces and 1 seat. The caveat: LangSmith costs roughly $2,514/month at 1M base traces. Scale fast and the bill gets real.
Langfuse is the open-source baseline. Langfuse is the open-source entry in the category—the core is MIT-licensed and can be self-hosted end-to-end, with a managed cloud available for teams that prefer SaaS. It covers tracing, datasets, evaluations, prompt management, and cost tracking. Pricing verified as of June 2026: Cloud is free to 50K units a month; Core is $29/month for 100K units with unlimited users; overage is $8 per 100K units—at 1M events a month, Core works out to about $101, versus roughly $2,514 on LangSmith Plus. For cost-sensitive teams not locked into LangChain, the cost delta is the entire argument.
Arize Phoenix is worth a serious look if you want self-hosted observability with zero feature gates. Phoenix is fully self-hostable with zero feature gates—runs locally, in Jupyter notebooks, Docker containers, or cloud environments. The managed upgrade path, AX Pro, runs $50/month for small teams running production LLM apps.
Arize AX is the managed AI engineering platform, while Phoenix is the open-source project for tracing and evaluation—both build around OpenTelemetry and OpenInference, which lets teams instrument agents across model providers and frameworks without tying the trace schema to one orchestration library.
For teams running CrewAI or similar multi-agent frameworks, multi-agent visibility is the deciding factor. Look for platforms that surface which agent or sub-agent handled each step, where coordination failed, and how downstream decisions changed—especially important in multi-agent systems where planners, routers, tools, and sub-agents may each have their own prompts.
The OTel Standard: Don’t Let Vendors Own Your Traces
One architectural decision that pays compound dividends: instrument with OpenTelemetry from day one. OTel GenAI Semantic Conventions establish a standard schema for tracking prompts, model responses, token usage, tool/agent calls, and provider metadata—defining a consistent vocabulary for spans, metrics, and events across any GenAI system, making AI observability measurable, comparable, and interoperable across frameworks and vendors.
Major vendors including Datadog, Honeycomb, and New Relic already support these conventions, and frameworks such as LangChain, CrewAI, AutoGen, and AG2 emit OTel-compliant spans natively or via instrumentation packages. The practical upside: you can swap or stack backends without re-instrumenting your codebase. One caveat worth noting— as of May 2026, the GenAI and MCP semantic conventions remain in Development status , so treat the spec as stable enough to build on but expect continued evolution.
Guardrails: The Layer That Keeps Agents Honest at Runtime
Tracing and evals catch what went wrong. Guardrails prevent it from reaching users in the first place.
AI guardrails platforms are runtime safety layers that validate, filter, and enforce policies on LLM inputs and outputs before they reach end users—addressing generative AI-specific failure modes: hallucinations, prompt injection attacks, PII leakage, toxic content generation, and off-topic drift.
Prompt injection and sensitive information disclosure sit at the top of OWASP’s 2025 Top 10 for LLM applications, and they are the two risk classes guardrails most directly address. For agents with real-world tool access—writing to databases, sending emails, calling APIs—this isn’t optional infrastructure. The sharp annual increase in AI safety incidents makes one thing clear: guardrails are critical production infrastructure, not an optional layer you bolt on later. Operating without systematic runtime protection means every deployed agent is one adversarial input away from a compliance violation, data leak, or reputational incident.
On the open-source side, tooling includes NVIDIA NeMo Guardrails, Guardrails AI, Meta’s Llama Guard, and Microsoft Presidio, each covering a different slice of the pipeline. On the commercial side, Fiddler stands out for latency: its standout capability is real-time guardrails with sub-100ms response time to detect and moderate risky prompts and responses, with built-in scoring for hallucinations, toxicity, PII leakage, and prompt injection attacks.
Critically, guardrail verdicts should live in the same trace as the LLM call that triggered them. Langfuse records guardrail verdicts as scores attached to the exact trace they protected—the verdict that blocked a response sits on the same trace as the LLM call, its inputs, and its outputs, so drilling from a spiking check to the offending prompts is a click, not a cross-store join.
When monitoring guardrails in production, production teams monitor violation rates, false-positive rates, and per-check latency the same way they monitor error rates. Overblocking is a real cost: if users see frequent overblocking or odd refusals, you are trading away utility—measure false positive rates and tune the rules instead of turning them off.
Connecting It to Your Coding Stack
If your team ships agents with Claude Code or iterates in a tight dev loop, the gap between “trace viewer” and “actionable feedback” matters more than feature lists. The emerging pattern is connecting observability signals directly back to the dev environment—some platforms now offer MCP integrations that let detected failures drive toward a code fix without leaving the agent coding context. Worth watching as the tooling matures.
The Bottom Line
Observability for production agents isn’t one tool—it’s a stack: OTel-native tracing for full session visibility, a structured eval layer that turns production failures into regression suites, and runtime guardrails that intercept unsafe outputs before they ship. The platform choice (LangSmith, Langfuse, Arize Phoenix, or others) matters less than wiring all three layers together from day one. Teams that skip this infrastructure don’t discover agent failures from their monitoring—they discover them from their users.