LangSmith adds end-to-end OpenTelemetry support for LangChain and LangGraph

LangSmith, the debugging and monitoring platform for LLM applications from the LangChain team, has announced full OpenTelemetry support. Developers can now plug AI-component tracing into the same observability stack as the rest of their application's services, instead of maintaining two isolated monitoring tools side by side.

Why AI services need OTel

OpenTelemetry (OTel) is an open CNCF standard for collecting distributed traces, metrics and logs. Nearly all major monitoring platforms support it: Datadog, Grafana, Honeycomb, Jaeger, AWS X-Ray, New Relic. In production systems, OTel has become a de facto requirement: it lets teams follow a user request across dozens of microservices, databases and external APIs within a single time context.

Until now, AI components lived in a separate bubble. LangSmith stored LLM call traces in a proprietary format, while the team's other infrastructure sat in an OTel backend. During every production incident, engineers had to switch between the two systems and manually match timestamps and call context. That slowed diagnosis and created blind spots in observability.

What changed in LangSmith

The new OTel support works in both directions and covers the entire LangChain ecosystem:

• Trace ingestion: LangSmith accepts data through a standard OTel collector, with no custom SDKs or special adapters
• Data export: LLM calls and agent traces can be sent to any OTel-compatible backend, including Datadog, Grafana Tempo, Honeycomb and Jaeger
• End-to-end context: distributed traces are linked across service boundaries, from the user's incoming HTTP request to the language model's response and back
• LangGraph support: beyond LangChain's linear chains, OTel tracing also covers complex LangGraph graph agents, with loops, parallel steps and conditional branches

The key change for engineers: a separate LangChain SDK is no longer needed to instrument the AI layer. A standard OTel agent already configured for the backend starts collecting data from LangSmith automatically.

What teams get in production

Take a typical incident: a user complains that a chatbot's reply takes 10–15 seconds. Previously, an engineer would open LangSmith, examine the language model call trace, then switch to Datadog to check network, queue and database latency, stitching the picture together by hand.

Now the entire request path, from the frontend through the API gateway and orchestrator to the LLM call and final response handling, appears in one continuous trace with millisecond precision.

For teams moving prototypes to production load, this means standard OTel practices such as alerting on p95/p99 latency, SLO metrics and error budgets now apply to AI components without extra configuration.

"End-to-end observability is not just a convenience; it is a mandatory

requirement for any production AI system that serves real users under real load."

For enterprise customers, it matters that corporate IT departments have already invested in OTel infrastructure and have strict standardization requirements. A new tool that requires its own isolated dashboard is always an extra barrier to getting adoption approved. LangSmith removes that barrier.

What this means

LangSmith is moving toward standardizing AI observability. Instead of the proprietary "everything only in our UI" approach, it offers an open standard that fits naturally into a team's existing tooling. That makes monitoring AI systems part of the ordinary engineering process rather than a separate discipline with its own data silo.

For the market as a whole, it is one more step toward AI infrastructure being seen as a standard part of the production stack, not an exotic add-on.