Claude Agents Now Export OpenTelemetry Traces — What That Changes for a Business Running Them

What actually shipped

OpenTelemetry (OTel) is the vendor-neutral tracing standard most observability platforms already speak. Anthropic's own writeup describes the change plainly: “the Claude API and the SDK can trace your Messages API requests, tool uses, and Managed Agents sessions with OpenTelemetry spans,” viewable “in the observability platform you already have.” (Claude Platform Docs). A trace is the full record of one request through the system; a spanis one step inside it — a model call, a tool use, an agent turn. Set up SDK tracing, API tracing, or both, and the spans line up into one readable timeline of what Claude did, in what order, and how long each step took.

The coverage is specific, not a marketing gloss. Per the docs, API tracing captures every model run inside a request, every Managed Agents turn, and every server tool the API runs; SDK tracing adds client-run tools and self-hosted sandbox activity. Twelve named destinations accept the traces out of the box — Datadog, Grafana Cloud, Honeycomb, Sentry, Splunk, New Relic, PostHog, Langfuse, LangSmith, Arize AI, Braintrust, and Databricks — plus any other platform that accepts a standard OTLP endpoint. Anthropic's companion article on the launch is at claude.com/resources.

Two customers, two different uses for the same trace

Anthropic's launch article names two companies already running this in production, and the two cases pull in different directions — which is the useful part. FloQast, whose agents touch close-the-books accounting work, frames it as an audit requirement: “agents that touch a company's books have to show their work,” and native trace export means the team can “answer from one timeline” when a question comes up later. Ramp, on the other side, is using the same traces for cost control — an engineer there reports a 10–20% reduction in token usage by finding waste in trace data that was previously invisible.

Same feature, two jobs: one company is using it to answer “can you prove what happened,” the other to answer “where is the money going.” A business implementing Claude agents should expect to need both answers eventually, often from the same trace data.

The setting that actually matters: content mode

The detail worth reading before flipping this on is the content mode setting, because it is the one choice that determines whether a trace is a debugging tool or a compliance liability. Per the docs, every destination defaults to Metadata only: spans carry identifiers, timing, status, and token counts, but not the actual prompts or responses. Switching a destination to Full contentadds the model's prompts and outputs to the span — genuinely useful for debugging a failed run or building evals from real traffic, but it means your conversation content is now also living inside whatever third-party observability platform you pointed it at, under that platform's own retention and access rules, not Anthropic's.

Anthropic builds in one hard guardrail here: “if your organization has a HIPAA, FERPA, or K-12 data-handling restriction with Anthropic, destinations export only metadata regardless of their content mode.” Everyone else has to make that call themselves, destination by destination. The docs also note a wrinkle worth knowing before you promise a client zero data retention: Messages API traffic stays eligible for zero data retention even with Full content on, but Claude Managed Agents is not eligible for zero data retention at all, regardless of the OTel setting. If your implementation runs on Managed Agents, that retention posture was already true before this feature shipped — OTel doesn't change it, but it is exactly the kind of fact a business should have in writing before an agent starts touching sensitive workflows, not discover during a security questionnaire.

Turning this on, concretely

What a trace still doesn't tell you

A trace is a record of what an agent did. It is not a verdict on whether the agent should have done it. OTel export tells you the bash tool ran, which files a Managed Agents session touched, how many tokens a turn burned, and how long it took — it does not tell you whether the output was within the role's written permissions, whether a qualified person reviewed it before it reached a client, or whether the result matches the standard your firm actually committed to. Those are governance questions, and they sit on top of the trace, not inside it. A business that wires up OpenTelemetry and stops there has better debugging. A business that wires it up andhas a written rubric for what “good” looks like, with a named reviewer and a retained record, has an audit trail.

Where Skoor fits

Skoor implements Claude's own apps and Managed Agents on a business's own hardware, then layers the governance that a technical trace alone doesn't provide: a written, versioned profile per role and per agent, continuous scoring against that profile, and a dated record retained in a store the business controls — the pieces described on Skoor's solutions page. OpenTelemetry gives a business the raw record of what Claude did; a reviewable, scored, retained standard for what Claude should have done is the layer Skoor adds on top, whichever observability platform the trace data happens to land in.