Claude Platform Adds OpenTelemetry Observability Through Databricks MLflow

Databricks said the Claude Platform now supports native OpenTelemetry observability, making Databricks MLflow a supported destination for trace export from Anthropic SDKs, the Messages API and Managed Agents. The capability is in Public Beta. Databricks describes a workflow in which Claude spans arrive through Zerobus Ingest and are stored in Unity Catalog tables linked to an MLflow experiment. Databricks report.

What Databricks Says Is Being Connected

In a blog post published November 3, 2026, Databricks said Claude's native instrumentation generates spans for model requests and tool calls and exports them using the OpenTelemetry Protocol. Databricks receives those spans through Zerobus Ingest and stores them in Unity Catalog tables tied to an MLflow experiment.

The Documented Setup: Three Steps

Databricks lays out a three-step connection. First, users create an MLflow experiment in the Experiments tab, keeping Unity Catalog as the trace storage location and selecting a catalog and schema; this links the experiment to the table storing OpenTelemetry traces.

Second, users set the Databricks destination using workspace ID, region and spans table, with a Zerobus connection guide covering a table-scoped OAuth token. The native integrations cover Anthropic SDKs, the Messages API and Managed Agents, while Claude Code and Claude Agent SDK support OpenTelemetry through additional variables. Third, users run an agent and open Traces to view model calls, tool activity, timing and captured inputs and outputs. Databricks notes inputs and outputs are captured only when content mode is set to full.

Debugging and Finding Repeated Failures

Databricks says an unexpected answer can stem from missing context, a failed tool call or how a model used a tool result. Its Analyze trace action brings Genie Code into the investigation to help explain where an execution went wrong and to support follow-up questions.

MLflow Issues, also in Beta, uses Genie Code to identify recurring quality and operational problems, grouping findings with supporting traces. Databricks says detection can be scheduled and focused using metadata or tags. A scorer can establish a baseline and sample new traces after a fix.

Expert Review and Evaluation Loops

Databricks says some quality judgments require domain knowledge, which MLflow Review Queues address by presenting selected traces and questions to reviewers. Reviewers can assess a recorded request and response, explain what is missing and provide an expected answer, which Databricks says helps developers refine agents and establish reference answers for later evaluations.

For measuring change, Databricks points to MLflow Agent Evaluation on Claude traces, testing whether modifications to prompts, skills or tools improve an agent or cause regression. When original and revised agents run against the same cases, their evaluation runs can be compared with the same judges; the post shows a judge checking for redundant tool calls. Our assessment is that the evaluation workflow should be used to measure changes, not to assume a benefit.

What This Means for Practitioners

Our recommendation is to treat this as an observability integration to pilot rather than a demonstrated quality fix. Teams already using Anthropic SDKs or Managed Agents and Databricks should confirm Public Beta limits, permissions, SQL warehouse requirements and the OAuth token process before routing production traces. Because Databricks states inputs and outputs are captured only under full content mode, teams should decide deliberately what is recorded, given that agentic traces can contain sensitive data. Access controls and query behavior in Unity Catalog warrant review before broad rollout.

We suggest starting with a narrow set of cases and comparing baseline and revised agents with the same judges. Practitioners should treat trace findings as investigative aids requiring validation, not verdicts. Whether tracing reduces unnecessary work or improves reliability should be measured in the deployment being evaluated.