Trace agents with OpenTelemetry on the Claude Platform
Claude’s new OpenTelemetry export isn’t really about prettier dashboards. It’s about making agent access feel earned: trace the model calls, tool use, and MCP steps first, then widen permissions when the agent proves it can behave. That matters because observability is now part of the product contract, not a sidecar. The interesting move is that Claude is trying to make its agents fit into the same tracing stack teams already use for the rest of their systems, so adoption friction drops instead of rising.
Transcript
Justy Okay, that part is the whole story: trace the agent first, then let it earn more access. That’s a very different product pitch from “here’s another dashboard nobody opens.”
Cody Yeah. And the mechanics are pretty specific here. Claude Managed Agents, the Messages API, and the SDKs can emit OpenTelemetry traces with latency, tokens, IDs, model calls, tool calls, and MCP server calls. That’s not hand-wavy observability vapor.
Justy Which is why this actually feels like an adoption feature, not just infra garnish. If you can already see Claude Code and Cowork traces in one place, adding your platform agents into the same tool chain is a real workflow win.
Cody Right, and the trust logic is sane for once. You review the traces, see where it’s calling tools, where it’s slowing down, where it’s maybe doing something dumb, and then widen access. That’s how you keep an agent from wandering into production with a fake halo around it.
Justy Also, this is the kind of thing that gets bought by the people who hate surprises. Platform teams, security teams, the folks who want receipts before they let an agent touch anything interesting. That’s the customer story, not “look, a shiny trace graph.”
Cody Mm-hm.
Justy And the article’s examples are actually good ones. Grafana Cloud, Honeycomb, Sentry, Splunk, all the usual places where logs and metrics already live. If the agent trace sits next to the slow service or the failed step, you stop arguing about whether the model was the problem or the downstream API was the problem.
Cody That part I buy. The OpenTelemetry GenAI semantic conventions matter because they make Claude traces look like the rest of the stack, not a special snowflake format that needs a separate viewer. And once you get that, the interoperability story is finally boring in the good way.
Justy Boring in the good way is such an Exploring Next sentence. We should probably print that on a mug and then immediately regret it.
Justy But seriously, the strongest product angle is the one with production data feeding back into evals. The article name-drops Arize, Braintrust, Datadog, Langfuse, LangSmith, New Relic, PostHog. That’s the loop teams actually want: real traces, then a way to ask whether the change helped.
Cody That loop is only as good as the trace fidelity, though. If the instrumentation drops a tool call or collapses distinct turns into mush, your evals get optimistic fast. So I’d be a little careful about treating “native export” as automatically enough; it’s necessary, not magic.
Justy Sure, but necessary is the thing that ships. Ramp’s quote is the most concrete one: they say Reflect already cut token usage by ten to twenty percent and made sessions thirty percent faster on some agents. That’s the kind of number that makes a product team sit up.
Cody I like that quote too, because it points at the real constraint. Reflect can only improve what it observes. If Claude is now feeding high-fidelity traces directly into that loop, then the boring plumbing is actually part of the optimization story.
Justy And then there’s the governance angle with Databricks Unity Gateway. That’s not sexy, but it’s exactly the part that turns “we have agents” into “we can explain token spend by team and flag weird usage.” You know, the stuff that keeps the lights on.
Cody Yeah, that’s the hidden second half of the article. Observability is not just debugging, it’s permissioning and accountability. If an auditor asks what an agent did and why, a single timeline with the prompt version, tool calls, latency, and token spend is a much better answer than a Slack thread and a prayer.
Justy That Foxglove quote is the one I’d show a buyer. Product usage data next to agent interactions is the kind of thing that turns “we think this helped” into “we can actually see where it helped.”
Cody And that’s the part I’d push on a little. The article leans on customer quotes more than hard benchmarks, which is fine for a product note, but it means the main claim is still about fit and workflow, not some universal technical breakthrough. Which is okay. Honestly, that’s better than pretending otherwise.
Justy Yeah, no, that’s fair. It’s a platform move, not a moonshot. But for teams already building on Claude, being able to drop traces into the same observability tool they already trust is a real reduction in friction. That’s the whole ballgame more often than people want to admit.
Cody And if they keep the export clean and truly standard OTLP, I think this lands. If it turns into a Claude-only interpretation layer wearing an OpenTelemetry hat, then people will get annoyed fast. But the article at least points the right direction.
Justy So, public beta, same tools, one timeline, fewer excuses. That’s a pretty good Wednesday for a boring infrastructure launch.
Justy Come on, Cody, let me have one enthusiasm per episode. We’ve been doing this almost a year and I’m still not allowed one?