What are the best AI agent observability platforms in 2026?

Last updated: September 2026

Choosing an agent observability platform starts with the problem the team needs to investigate. A failed agent run calls for traces that show model responses, tool calls, and errors. A review of access to production data also needs evidence of whose authority the agent used and which policy allowed the call. A purchase made for debugging may leave that second requirement unresolved.

This comparison covers LangSmith, Datadog, Arize, Fiddler AI, and Speakeasy. We assess them against two needs: engineering telemetry for debugging and evaluation, and tool-call audit for access reviews. The useful shortlist depends on which evidence is missing from your current setup.

LangSmith, Datadog, Arize, and Fiddler AI offer tracing and evaluation capabilities. Speakeasy provides audit records through its AI Control Plane. We explain where each fits and what additional tooling a team may need. That audit record also keeps an agent inventory current and binds the person, agent, client, and task into a composite identity.

Why "agent observability" means two different jobs

The phrase gets used for both jobs because both produce a record of agent behavior. The records answer different questions for different readers.

Tracing and evaluation for engineering teams

Trace-side platforms instrument the agent application itself. They capture spans for model calls and tool invocations, assemble them into traces and sessions, and layer evaluations on top. These can include LLM-as-judge scoring, drift detection, hallucination and faithfulness metrics, and experiments that compare prompt or model changes against production data. The reader is an AI engineering team asking why the agent acted as it did and whether it is improving.

LangSmith, Datadog, Arize, and Fiddler AI all provide capabilities in this category, often using OpenTelemetry instrumentation.

Tool-call and identity audit for security teams

Audit-side observability records what agents were allowed to do and what they actually did, from a position the agent cannot skip. A gateway on the path between agents and the systems they reach logs every Model Context Protocol (MCP) tool call with the identity that made it, resolved against the identity provider rather than self-reported, along with the policy decision and the data scope involved. The reader is a CISO, CIO, or compliance team, and the question is "who did what, through which tool, against which system?"

The two records are not interchangeable:

• Trace telemetry is emitted by instrumented code. An agent that is misconfigured, unapproved, or malicious may emit nothing.
• Trace metadata carries whatever user ID the application chose to attach. An audit record needs identity the platform verified.
• Traces live in an engineering tool. Audit evidence needs to be immutable, attributable, and exportable to the SIEM the security team already runs.

Willow, an agent identity and access vendor, also discusses identity-linked audit beside tracing tools in its roundup of agent observability platforms. This article makes the case from the gateway side.

How we evaluated AI agent observability platforms

We compared each platform on the capabilities the two jobs actually require, checked against public product pages and documentation as of September 2026:

• Tracing depth: spans, traces, sessions, and the debugging workflow around them.
• Evaluation: scoring quality in development and production, from LLM-as-judge to drift and hallucination metrics.
• Instrumentation: OpenTelemetry support and framework coverage, so telemetry isn't locked to one orchestration library.
• Identity and audit: whether tool calls are attributed to a verified identity from the IdP, and whether the record stands up as audit evidence.
• Position: whether the platform observes from beside the traffic or sits on the request path where it can also enforce.

How do AI agent observability platforms compare?

A ✅ means the capability is native and documented, ⚠️ means it is partial or conditional, and ❌ means it is absent. The profiles below explain each row.

LangSmith: agent tracing and evals from the LangChain team

LangSmith is a framework-agnostic platform for observing, evaluating, and deploying agents, built by the LangChain team. It traces full conversations and agent runs step by step, tracks cost, latency, and errors through dashboards and alerts, and runs LLM-as-judge, code-based, and multi-turn evaluators on production traces, with annotation queues for human review.

LangSmith Engine uses production traces to cluster recurring failures into prioritized issues and diagnose them against traces and code. It proposes prompt or code fixes and can open a GitHub pull request for review when a repository is connected. Instrumentation runs through the LangSmith SDKs or OpenTelemetry, with integrations for LangChain and LangGraph.

Where it fits: AI engineering teams debugging and iterating on agents, particularly teams already building on LangChain or LangGraph.

Where it stops: LangSmith observes the application from inside it. User attribution is whatever metadata the application attaches, not identity verified against your IdP, and there is no gateway position from which to record or block a tool call the instrumented code didn't report.

Datadog: agent observability inside an existing APM estate

Datadog Agent Observability extends its monitoring platform to agents: end-to-end LLM tracing, datasets and experiments, offline and online evaluations, human review, and production monitoring in one workflow. Its AI Agent Monitoring maps each agent's decision path (inputs, tool invocations, calls to other agents, and outputs) in an interactive graph, and the AI Agents Console, announced in preview in June 2025, extends visibility to third-party agents.

Datadog's structural advantage is correlation. Agent traces land beside the APM, infrastructure, and log telemetry the organization already ships to Datadog, so an engineer can move from a failing LLM span to the service and infrastructure signals underneath it without switching tools. Instrumentation covers Python, Node.js, and Java SDKs plus OpenTelemetry and an HTTP API, with support for OpenAI, Anthropic, Gemini, LangChain, CrewAI, Bedrock, and other frameworks.

Where it fits: engineering organizations already running Datadog that want agent telemetry in the same pane as everything else.

Where it stops: Datadog observes agent behavior. It is not positioned between an agent and the tools it calls, does not broker MCP access, and does not bind agent actions to IdP-verified identity.

Arize AX and Phoenix: OpenTelemetry-native tracing and evaluation

Arize ships two related products. Phoenix is its open-source tracing and evaluation platform, which runs locally or self-hosted, and Arize AX is the managed platform built on the same foundations, adding agent trajectory visualizations, online evaluations, dashboards, monitors, and human annotation workflows. Both are built on OpenTelemetry plus OpenInference, the AI semantic-convention standard Arize created and maintains, so traces aren't locked to a proprietary format.

In August 2026, Arize added native normalization of OpenTelemetry GenAI semantic conventions, so applications that already emit gen_ai.* spans can send telemetry directly to AX. It has also proposed donating its OpenInference instrumentation libraries to the OpenTelemetry project.

Where it fits: evaluation-heavy teams that want span-, trace-, and session-level evals, and teams that want an open-source, self-hostable starting point in Phoenix.

Where it stops: the same boundary as the other trace platforms. Arize sees what instrumented applications report, so it has no independent record of tool calls, no gateway logs, and no IdP-bound identity on agent actions.

Fiddler AI: enterprise agentic observability and model risk

Fiddler AI comes at agent observability from the enterprise-risk side. Its agentic observability traces hierarchically from application to session to agent to trace to span, runs root cause analysis to pinpoint the failing span, and applies 100+ quality metrics through its in-environment Centor Models, which score inputs and outputs without external API calls. It supports OpenTelemetry and frameworks including LangGraph, Amazon Bedrock, AWS Strands Agents, and Google ADK, and its guardrails product scores safety, faithfulness, and PII as a low-latency API.

Fiddler repositioned as the "AI Control Plane for Enterprise Agents" alongside its January 2026 Series C, which invites a comparison we've already written in full: see Speakeasy vs Fiddler AI. The short version is that Fiddler observes and scores from beside the traffic, and its guardrails return scores that the application's own code acts on, while its RBAC governs access to the Fiddler platform rather than which agents can reach which tools.

Where it fits: ML and AI engineering teams debugging multi-agent systems, and model risk management functions in regulated industries that need evaluation evidence.

Where it stops: Fiddler's audit trail is behavior-centric, built around agent and model quality rather than who was allowed to call which tool. It ships no MCP gateway, server registry, or credential management.

Which open-source AI observability platforms should you consider?

The trace-APM side of this market includes more than the four platforms profiled above. Langfuse is an MIT-licensed AI engineering platform with hierarchical tracing, evaluations, prompt management, cost dashboards, OpenTelemetry support, and a self-hosting option. Teams considering open source can evaluate it alongside Phoenix. Evaluation-first platforms such as Braintrust are also relevant to the category.

Speakeasy: the tool-call and identity audit layer

Speakeasy is an AI Control Plane, and its observability is the audit kind. Its MCP gateway sits on the path between agents and the systems they reach, so agent observability comes from the gateway's own logs rather than from instrumentation the application volunteers: every session, tool call, and token is recorded as it happens and attributed to a named person, team, and agent, with identity resolved against your IdP rather than self-reported by the application.

For traffic routed through the gateway, the audit record includes:

• Tool-call audit: one searchable trail of who asked what, when, through which MCP tool, against which system, including calls from agents nobody instrumented.
• IdP-bound identity: every action maps to a verified employee or service identity, so attribution survives an audit rather than depending on app-supplied metadata.
• Policy in the same record: blocks, approvals, and budget events sit in the trail beside the calls they governed, because the same gateway enforces them.
• Evidence workflows: the trail exports to the SIEM, BI tools, and warehouses the security and finance teams already run, and the platform holds SOC 2 Type II and ISO 27001, per our security page.

Where it fits: CISO, CIO, and platform teams that need to answer which agent called which tool as which identity, enforce policy on that path, and hand auditors evidence rather than instrumentation.

Where it stops: Speakeasy does not do span-level tracing, evaluations, or drift and hallucination scoring, and it does not sell OpenTelemetry pipelines. Teams that need to debug agent quality should run a trace platform from the first half of this list, and the two records complement each other rather than compete.

For teams evaluating the runtime layer rather than only its logs, AARM provides a vendor-neutral checklist for pre-execution interception, identity binding, policy decisions, and tamper-evident receipts.

Do you need OpenTelemetry for agent observability?

For the tracing job, OpenTelemetry is the default transport, and every trace platform here either accepts or emits it. Its GenAI semantic conventions define the vocabulary for agent spans (operations like invoke_agent and execute_tool), but they remain a moving target: the project moved all GenAI conventions into a dedicated semantic-conventions-genai repository in June 2026, and as of September 2026 the conventions are marked as in development, with no stable release to pin against.

For access reviews, check where the evidence originates and how identity is verified. Application traces depend on what the instrumented application reports, so missing instrumentation can leave gaps. Logs from a gateway that brokers access can provide a separate record of the calls passing through it. A telemetry format alone doesn't establish that coverage or attribution.

How to choose an AI agent observability platform

Start with the job the platform needs to do.

When should you choose an agent tracing platform?

Choose a trace platform when the question is why an agent failed and whether the next version is better. LangSmith fits LangChain-centric teams, Datadog fits organizations already standardized on its APM, Arize fits evaluation-heavy teams and open-source adopters via Phoenix, and Fiddler fits enterprises that want observability tied to model risk management.

When do you need a tool-call audit layer?

Choose an audit layer on the request path when the question is which agent called which tool as which identity, and whether policy was enforced on that call. That is the job Speakeasy is built for.

When should you use both tracing and audit?

Organizations operating agents in production may need both. Traces flow to the evaluation platform while the gateway writes the audit trail. Neither record replaces the other.

Shortlist platforms by your team's needs

Before choosing, test the shortlist against a failed agent run and a tool call that needs an access review. Check whether the platform provides enough context to explain the failure, identify the caller, and establish which policy applied. That exercise will show which requirements it covers and where another source of evidence is needed.

Questions about this roundup, or think we've got something wrong? Talk to our team.