Why does OpenTelemetry's GenAI semantic-convention spec matter for choosing an observability stack in 2026?

Short answer·Hard·4.0 · 0·~3 min·Asked atMicrosoft Databricks NVIDIA

Attempt it

Explain why OpenTelemetry's GenAI semantic-convention spec matters for picking an observability stack in 2026, and what specifically you lose by going with a proprietary surface like LangSmith instead.

Free · 2 AI evals / day

OpenTelemetry (OTel) is the industry-standard observability framework. Traces, metrics, and logs with a vendor-neutral protocol. The GenAI semantic-convention spec is an addition that defines a standard set of attribute names for LLM-related spans. Key GenAI attributes include: - `gen_ai.system`. The provider name (openai, anthropic, google). - `gen_ai.request.model`. The model id (gpt-5.5, claude-sonnet-4-6). - `gen_ai.usage.input_tokens` and `gen_ai.usage.output_tokens`. Token counts. - `gen_ai.response.finish_reasons`. Why the model stopped. - `gen_ai.operation.name`. One of chat, embeddings, or tool_call. Why this matters: if your instrumentation emits these standard names, any OTel-compatible backend can read your traces. Langfuse, Phoenix, Datadog, Honeycomb, Grafana Tempo. All of them speak OTel. Switching from one to another is an exporter config change, not a re-instrumentation pass. LangSmith is the counterexample. Its trace format is proprietary and tightly coupled to LangChain. Every line of LangChain code is implicitly instrumented for LangSmith. Leaving LangSmith means migrating off the trace format too, which is a re-instrumentation cost. In 2026 this matters more than it did in 2024 because OTel GenAI conventions are stable and most vendors have adopted them. The decision to instrument against OTel or against a proprietary surface is the decision about whether you can change your observability vendor cheaply in the future.

OpenTelemetry's GenAI semantic conventions standardise the attribute names on LLM-related spans. Names like `gen_ai.system`, `gen_ai.request.model`, `gen_ai.usage.input_tokens`, `gen_ai.usage.output_tokens`, `gen_ai.response.finish_reasons`, `gen_ai.operation.name`. The spec also defines event schemas for prompts, completions, and tool calls. The win is that instrumentation becomes one-time and portable. Emit spans with those attribute names from your code (via the official OTel GenAI instrumentation libraries, or by hand) and any conformant backend can read them. Langfuse, Phoenix (Arize), Datadog APM, Honeycomb, Grafana Tempo, Jaeger. Every major vendor that has invested in GenAI tracing speaks OTel. Switching backends is an exporter-config change, not a re-instrumentation pass over every call site. LangSmith is the conspicuous proprietary outlier. Its trace format is its own; it's tightly coupled to LangChain (LangChain emits LangSmith traces via callbacks by default); and it has not converged with the OTel GenAI conventions. Adopting LangSmith means every LangChain span in your codebase is implicitly LangSmith-shaped. The cost of leaving LangSmith is re-instrumenting against OTel. In 2026 the GenAI conventions are stable enough that 'use OTel' is the default-correct answer. Both the spec and the backends have hardened. The trace format is the lock-in, not the dashboard.

Quick reference

TL;DR

OTel's GenAI conventions standardise LLM-trace attribute names so any conformant backend reads them. Instrument once, switch vendors via exporter config, dodge proprietary lock-in.

Memory aid

Easy to grasp

Imagine every electrician used a different colour code for live, neutral, and earth wires. To swap from one electrician to another, you'd have to rewire every socket in the house. Then everyone agreed on a shared colour code, black, red, green, and now any electrician can plug into any house and read the wires correctly. OpenTelemetry's GenAI conventions are that shared colour code for LLM traces. Once your code emits standard attribute names, any monitoring vendor that reads OpenTelemetry can use your traces. If you instead used a vendor whose colours only their own electricians can read, leaving them means rewiring the house.

Key concepts

LLM frameworks

Detailed answer & concept explanation

~5 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.

Quick scan · 2–4 min

Everything important, quickly.

6 minutes: what the GenAI conventions standardise, why trace format is the lock-in, the leading conformant instrumentation libraries, and the LangSmith counterexample.

Code example

python

# Emit OTel GenAI traces from LangChain without LangSmith lock-in
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter
from openinference.instrumentation.langchain import LangChainInstrumentor

provider = TracerProvider()
provider.add_span_processor(
    BatchSpanProcessor(
        OTLPSpanExporter(endpoint="https://your-backend/v1/traces")
    )
)
trace.set_tracer_provider(provider)

# One line wires LangChain to emit OTel GenAI conventions on every call
LangChainInstrumentor().instrument()

# Now switch backends by changing the exporter endpoint: Langfuse, Phoenix,
# Datadog, Honeycomb, Grafana Tempo all parse the same trace shape.

Side-by-side

Aspect	OTel GenAI conventions	LangSmith (proprietary)
Trace format	Open spec, vendor-neutral	Proprietary, LangChain-coupled
Backend portability	Langfuse, Phoenix, Datadog, Honeycomb, Tempo	LangSmith only
Instrumentation effort	Once, with OTel SDK or OpenInference/OpenLLMetry	Implicit via LangChain callbacks
Cost to switch backend	Exporter config change	Full re-instrumentation
Best fit	Multi-vendor or open-source observability	Teams committed to LangChain + LangSmith ecosystem

Real-world examples

Real products, models, and research that use this idea.

Langfuse natively ingests OTel GenAI conventions and renders the standard attributes (system, model, token counts, finish reasons) without per-vendor mapping.
Arize Phoenix is OTel-native and uses the GenAI conventions as its primary trace format, with OpenInference as the complementary spec for LLM-specific events.
Datadog APM added GenAI conventions support in 2025; spans emitted from any OTel-conformant LLM SDK render in the GenAI Monitoring dashboard without custom mapping.
OpenInference (by Arize) and OpenLLMetry (by Traceloop) are the two leading OTel-conformant instrumentation libraries that emit GenAI conventions from LangChain, LlamaIndex, OpenAI SDK, and Anthropic SDK without code changes.

Interviewer follow-ups

What an interviewer would ask next. Try answering before peeking at the approach.

QHow would you migrate an existing LangChain + LangSmith codebase to OTel GenAI conventions?

QWhat about PII and prompt content in traces. How do the GenAI conventions handle it?

QHow does OpenInference relate to the OTel GenAI conventions?

Don't say this

Red flags and common mistakes that signal junior thinking. Click to expand.

Most common mistake

Treating observability vendor choice as a dashboard decision rather than a trace-format decision. And discovering, when migration is needed, that the trace shape itself is the lock-in.

60-second cheat sheet

The night-before-the-interview bullets. Scan these on the way to the call.

References

Primary sources. Skim if you want the original framing.