The alert came in at 11:43 PM. A CX agent handling password reset requests had started failing on a specific scenario: customers who had recently changed their email addresses. The escalation rate to human agents had tripled in the last forty minutes. The engineer on call opened the observability dashboard, found a batch of failing traces, and clicked into one.
The trace showed two things: the customer's initial message and the agent's final response. The response was wrong. What it didn't show was which tool the agent called before generating that response, what the tool returned, what the retrieval step pulled from the knowledge base, or which turn in the multi-step conversation the failure originated from.
The engineer spent ninety minutes working backwards from the wrong output, trying to reconstruct what the agent had seen. The culprit turned out to be a stale cache in the identity lookup tool, serving outdated email records. By the time they found it, it was 1:30 AM and 200 more customers had been told to contact support manually.
That's the gap most observability platforms leave in 2026. Not the absence of data. The presence of incomplete data that looks sufficient until you actually need to debug something.
Six platforms are worth evaluating in 2026. But the platform list is the wrong place to start.
The Three Criteria That Separate Useful From Useless
Useful agent observability requires three things, and Braintrust's 2026 guide emphasizes all three: the platform has to score what it captures, surface failing runs without manual querying, and turn production traces into the next test cycle. Miss any one and the data you collect stops being actionable. Those three criteria are the right frame for evaluating any platform you're weighing.
First, the platform must score what it captures. Logging LLM call inputs and outputs is table stakes. Scoring them, attaching a quality signal to each captured trace that tells you whether the agent behavior was correct, is what makes the data actionable. Without scoring, you have storage costs and manual querying. With scoring, you have automated failure detection.
Second, the platform must surface failing runs without manual querying. If finding your worst interactions requires you to write a query and remember to run it, you'll check infrequently and problems will accumulate. When did you last run that saved query? Effective observability pushes alerts to you. When the agent's quality score drops, when a tool error rate spikes, when a new failure pattern emerges, you should know before your customer does.
Third, the platform must turn production traces into the next test cycle. This is the hardest capability to ship and the most valuable to operate. When your agent fails on a real customer interaction, that interaction should automatically become a test case. The trajectory eval framework only makes your evals better if you have a mechanism to feed production failures back into it. Platforms that store traces but don't close that loop force you to manually curate test cases, which means your eval suite drifts behind reality.
Sinch surveyed 2,527 decision-makers across ten countries in early 2026 and found that 74% had rolled back a customer-communications AI agent after a governance failure. The common thread was that teams discovered problems post-launch rather than through continuous monitoring. Regulation is pushing the same direction: audit trails for agent behavior are moving from nice-to-have to expected, and the EU AI Act's transparency duties (more on those below) put real weight behind capturing what your agent did and why.
The core gap in how most teams approach production monitoring is not a platform problem. It's a category error: teams instrument agents like LLM wrappers instead of like distributed systems. Any platform you choose will only work as well as your instrumentation strategy.
What Does a Good Agent Trace Actually Look Like?
A complete agent trace for a CX interaction is hierarchical, and the platforms differ sharply in how much of it they capture. Three levels matter: the conversation scored end to end with cost, latency, and outcome; the turns inside it, each scored independently; and beneath each turn, the spans for every LLM call, tool invocation, retrieval query, and memory operation, with arguments, results, and timing.
The spans are where most platforms fall short. An LLM span should include the full prompt, the completion, token counts by category, and latency. A tool span should include the function name, the arguments the agent passed, the result returned, and whether the call succeeded or failed. A retrieval span should include the query, the documents retrieved, and ideally a relevance signal. A memory span should show the read or write operation, the key, and the value.
Without the tool arguments and results, you can't debug the case where the agent called the right tool with wrong arguments. Without the retrieval documents, you can't diagnose hallucinations from bad retrieval. Without memory spans, you can't trace context persistence failures.
The guide to what you should actually be tracing in production goes deeper on how to use this structure for root cause analysis. The point here is simpler: if a platform doesn't capture all of these span types, you're going to hit a debugging dead end the first time something goes wrong at a non-LLM step.
The Six Platforms, Evaluated
The six platforms stack up differently against the three criteria. Maxim AI and Braintrust lead on automatic scoring and failure surfacing, and Braintrust owns the trace-to-test loop. Langfuse and Phoenix win on self-hosting freedom and compliance. LangSmith is the default if you're already on LangChain, and MLflow fits teams already running Databricks.
One column deserves a warning before you read it. Every platform here has some self-hosting story, so "can I self-host" is the wrong question. The real question is what it costs you: Phoenix, Langfuse, and MLflow are free to run yourself, while Maxim AI, LangSmith, and Braintrust put it behind an enterprise agreement. Any comparison that prints a bare "no" in this column is out of date.
| Platform | Auto scoring | Failure surfacing | Trace-to-test loop | Self-host | Best for |
|---|---|---|---|---|---|
| Maxim AI | Strong | Strongest | Present, more manual | Enterprise, in-VPC or hybrid | Automatic failure surfacing, minimal config |
| Arize Phoenix | Configurable | Needs config | Assemble from parts | Free, no feature gating | Data residency, self-hosting |
| LangSmith | On LangChain | Native traces | Good, loop needs config | Enterprise plan | LangChain / LangGraph teams |
| Langfuse | Auto + human | Good | Good | Free, MIT core | EU compliance, audit trails |
| MLflow | Built-in judges | Needs config | Custom assembly | Free, open source | Existing MLflow / Databricks |
| Braintrust | Strong | Strong | Most mature | Hybrid data plane in your cloud | Teams with an eval practice |
Maxim AI
Maxim AI is the strongest of the six on the first two criteria: scoring what it captures, and surfacing failures without making you go looking for them. You'll see it near the top of vendor round-ups, though treat those rankings with suspicion. Most "best observability tools" lists are published by observability vendors, and they have a habit of ranking themselves first.
Maxim's default evaluation pipeline attaches quality scores to traces automatically using configurable LLM-as-judge evaluators. New traces get scored as they arrive, and failing runs appear in a dedicated view without requiring a query. For teams that want to go from "something is wrong" to "here are the specific failing traces" without writing SQL, this is currently the strongest out-of-the-box experience.
The third criterion, turning traces into test cases, is present but requires more manual configuration than Braintrust. Maxim's trace-to-dataset export is good. The automated pipeline for promotion from production observation to test suite is still maturing.
For CX agents, Maxim handles multi-turn trace hierarchy well and supports nested spans for tool calls. Its weakest area for voice-specific deployments is audio-trace linking, where dedicated voice platforms have an edge. Self-hosting is available but sits behind an enterprise agreement, either fully in your VPC or as a hybrid data plane.
Best for: Teams that want strong automatic failure surfacing with minimal configuration.
Arize AI (Phoenix)
Pick Phoenix when the conversation data can't leave your infrastructure. It's free to self-host with no feature gating, and that single property drives most of its adoption: teams with strict data residency requirements, research teams that want to modify the instrumentation layer, and companies that can't send conversation data to a third-party SaaS.
Phoenix's tracing is built on OpenTelemetry, but through Arize's own OpenInference conventions rather than the official OTel GenAI semantic conventions. That distinction matters more than it sounds. Traces emitted against the OTel GenAI spec have to be translated into OpenInference format first, so "it speaks OpenTelemetry" does not mean drop-in portability the way you'd assume. The observability pipeline from scratch article covers OpenTelemetry-based instrumentation that would work well with Phoenix.
One more thing worth knowing before procurement asks: Phoenix ships under the Elastic License 2.0, which is source-available rather than OSI-approved open source. For most teams that changes nothing. For anyone with a policy that says "OSI licenses only", it changes everything.
On the three criteria: Phoenix captures and stores well, and it supports configurable evaluators for scoring. Automatic failure surfacing requires more configuration than Maxim or Braintrust. The trace-to-test pipeline is not built in but can be assembled from Phoenix's components.
Best for: Teams with data residency requirements, self-hosting mandates, or a preference for running the infrastructure themselves.
LangSmith
Already on LangChain or LangGraph? LangSmith is the default, and the integration depth is why. Tracing turns on when you set LANGSMITH_TRACING=true, and you get full span capture, including chain steps and sub-agent calls, without writing a single instrumentation line.
Outside the LangChain tooling stack, LangSmith is a harder sell. The instrumenting-your-own-agent experience requires more work than the native path suggests.
LangChain's State of Agent Engineering survey found that 89% of teams have some observability in place, but only 52% run offline evals and nearly a third run no evals at all. LangSmith attacks that gap by surfacing run scores in the same interface as traces. The trace-to-dataset promotion is good, though the full trace-to-test automation loop needs custom configuration.
For CX agents not on LangChain, evaluate LangSmith on its standalone merits rather than its LangChain integration story. That's a different value proposition. Self-hosting exists on the enterprise plan, either fully self-managed in your own Kubernetes cluster or as a hybrid.
Best for: Teams already using LangChain or LangGraph who want zero-config tracing with native integration.
Langfuse
Langfuse is the platform to watch for European enterprise teams. Its core is MIT-licensed with a managed cloud option, and its documentation of trace structure and audit capabilities lines up with the EU AI Act's Article 13 transparency requirements for high-risk systems. Check your dates before you build a compliance case on this, though: the Digital Omnibus that entered into force in July 2026 pushed the Annex III high-risk obligations out to December 2027, while the Article 50 transparency duties (disclosing that a customer is talking to an AI) still apply from August 2026. The deadline moved. The audit-trail questions European teams are asking did not, and most US-centric platforms still haven't designed for them.
Beyond compliance, Langfuse has a clean API and strong community documentation. Its scoring interface lets you attach both automated and human-labeled scores to traces, which is useful for teams that need human review alongside automated evaluation.
The automatic failure surfacing and trace-to-test capabilities are good but not leading-edge compared to Maxim and Braintrust on those specific criteria. Where Langfuse wins is in the combination of a genuinely open licence and compliance readiness.
Best for: European enterprise teams, regulated industries, and any team that needs clear audit trail documentation alongside observability.
MLflow
MLflow is an unexpected name on this list. It's a traditional MLOps platform that has been the backbone of experiment tracking and model management for years. It earned a place here because of its 2026 agentic monitoring guide, which added specific support for agent traces alongside its existing model registry and experiment tracking.
For teams already invested in Databricks or MLflow's tooling stack, extending it to agent monitoring is lower friction than adopting a new tool. MLflow's strength is breadth: you can track experiments, evaluate models, and monitor production agents in one place.
The agent-specific observability capabilities are not as mature as purpose-built platforms. Nested span capture requires more instrumentation work, and the trace-to-test pipeline needs custom assembly. Scoring, though, is better than MLflow's MLOps reputation suggests: it ships around twenty predefined LLM judges covering correctness, safety, retrieval groundedness, and tool-call correctness, so you're not starting from zero. A couple of them run only on Databricks.
MLflow is a reasonable choice if the switching cost of a new tool outweighs the capability gap. For teams starting fresh with agent observability, the purpose-built platforms offer a faster path to the three criteria that matter.
Best for: Teams already running MLflow or Databricks who want to avoid adding another tool to their stack.
Braintrust
Braintrust closes the observability loop better than any other platform in 2026. Its trace-to-test pipeline, the ability to take a production trace and automatically promote it into your eval dataset, is the most mature implementation of the third criterion on this list.
The product design reflects a clear thesis: the best test cases come from production. When your agent fails on a real customer, that interaction is more valuable than any synthetic test you could write. Braintrust captures the trace, scores it, flags it as a failure, and makes it one click away from becoming part of your next evaluation run.
On the first two criteria, Braintrust is strong. It scores what it captures with configurable LLM-as-judge evaluators. It surfaces failing runs through dashboards and alerts. It's the platform that most explicitly connects observability to the eval workflow. If data residency is a blocker, note that Braintrust publishes Terraform modules for running the data plane, meaning your traces, datasets, and prompts, inside your own AWS, GCP, or Azure account.
For teams that have a mature eval practice and want their production data to improve it automatically, Braintrust is the right anchor. For teams still building their eval foundation, the automatic failure surfacing in Maxim may deliver more immediate value.
Best for: Teams with an existing eval practice who want production traces to feed into and improve their test suite continuously.
Where Do Most Platforms Fall Short for CX Agents?
Every platform on this list was designed primarily for LLM application developers, and CX agents expose the gaps. Four requirements consistently fall through: nested tracing across multi-agent handoffs, per-turn quality scoring inside a conversation, memory-operation tracking, and voice-specific signals like audio and transcript. Generic platforms handle some of these with extra configuration and miss others entirely.
Multi-agent handoffs are the most common gap. A voice CX agent that routes to a specialist agent for billing inquiries creates a parent-child trace structure. The parent agent span should contain the full conversation, the child agent span should contain the specialist interaction, and both should be linked to the same customer session. Most platforms flatten this into two disconnected traces that require manual correlation, which in practice means someone pasting session IDs between two browser tabs at midnight.
Per-turn quality scoring matters for multi-turn conversations in a way it doesn't for single-turn completions. A conversation that ends in resolution might have poor quality in turns three and four that only resolved because of a human taking over in turn seven. Per-turn scoring lets you identify the turns that are causing problems, not just the conversations that end badly. Most platforms score at the conversation level and require additional configuration for turn-level granularity.
Memory operations are invisible in most platforms. CX agents that read from and write to long-term customer memory have a distinct failure mode: the agent reads stale memory, acts on outdated information, and gives a wrong answer. Without memory span tracking that shows what was read, when it was written, and what the agent did with it, that failure mode is very hard to diagnose from traces.
Voice-specific context like audio recording, STT transcript, and TTFB (time-to-first-byte) are outside the scope of general-purpose observability platforms. For agents on voice channels, you'll typically need platform-specific tooling alongside your observability layer.
The monitoring feature covers what these gaps look like in practice for CX-specific deployments, including multi-turn trace structure and handoff tracking.
How Do You Choose the Right Platform?
Start with your team's current stack, because it narrows the list faster than any feature comparison. If you're on LangChain, evaluate LangSmith first before anything else. The zero-config path is worth testing against your actual agents before deciding whether you need to look elsewhere.
If you're building from scratch or your stack is framework-agnostic, make Maxim AI and Braintrust your primary comparison. Run both on a representative sample of production traffic and evaluate against the three criteria: how well does each one score traces automatically, how effectively does it surface failures, and how much work does the trace-to-test pipeline require?
If data residency or compliance is a constraint, add Langfuse to that comparison. If you need to self-host without signing an enterprise contract, Phoenix, Langfuse, and MLflow are the three that let you.
The scorecards feature is where you'll close the loop between what your observability platform captures and what changes you make to your agent configuration. Build the discipline of reviewing observability data before every agent update, not just when something breaks.
And for the scenario where you want to test your agent against adversarial inputs, edge cases, and the specific failure patterns your observability has surfaced, scenario testing is the right tool to build that discipline into your deployment workflow.
Three out of four teams in the Sinch survey pulled an agent back after a governance failure they found too late. Observability doesn't eliminate failures. It changes when you find them, and how long you spend staring at a wrong answer trying to work out why.
The engineer who lost ninety minutes to a stale cache at 1:30 AM didn't have a data problem. The dashboard had plenty of data. It just never captured the tool arguments or the retrieval results, the two spans that would have pointed straight at the cache. Pick the platform that captures those. That's the whole job.
Agent observability built for CX
Chanl captures nested traces for every agent call, including LLM turns, tool invocations, retrieval steps, and memory operations, with automatic conversion to test cases so your production data improves your evals. Built for the full build, connect, and monitor lifecycle of CX agents.
Start freeCo-founder
Building the platform for AI agents at Chanl — tools, testing, and observability for customer experience.
El briefing de Signal
Un email por semana. Cómo los equipos líderes de CS, ingresos e IA están convirtiendo conversaciones en decisiones. Benchmarks, playbooks y lo que funciona en producción.
