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 atKore Ai Observe Ai Razorpay

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.

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

Concept explanation~2 min read

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

Observability for LLM applications was a vendor by vendor mess through 2023 and most of 2024. Every tracer, LangSmith, Helicone, Arize Phoenix, Langfuse, Datadog, had its own trace shape, its own SDK, its own dashboard. Switching vendors meant a re-instrumentation pass over the entire codebase.

In late 2024 and through 2025, the OpenTelemetry community stabilised the GenAI semantic conventions, and the major LLM-observability vendors converged on supporting them. In 2026, this convergence is the single most consequential observability decision a team can get right or wrong. This deep dive covers what the conventions standardise, why the trace format is the real lock-in (not the dashboard), the two leading conformant instrumentation libraries, and why LangSmith is the conspicuous proprietary outlier.

What the GenAI conventions actually standardise

The OTel GenAI semantic conventions define a vocabulary for LLM-related spans: which attribute names go on which span, what values they carry, what operations exist, and how prompt/completion content is captured as events.

Core span attributes

gen_ai.system. The provider identifier. Values include openai, anthropic, google.gemini, aws.bedrock, azure.openai, mistral, and cohere.
gen_ai.request.model. The model id requested by the call (for example gpt-5.5, claude-sonnet-4-6, gemini-3.1-pro).
gen_ai.response.model. The model id the provider actually served (sometimes differs after routing).
gen_ai.request.max_tokens, gen_ai.request.temperature, gen_ai.request.top_p, gen_ai.request.frequency_penalty. Call parameters.
gen_ai.usage.input_tokens, gen_ai.usage.output_tokens. Token accounting.
gen_ai.response.finish_reasons. Array of finish reasons from the provider.
gen_ai.response.id. The provider's response id, useful for correlating with provider-side logs.

Operation names

Spans set gen_ai.operation.name to one of: chat, text_completion, embeddings, or tool_call. This is what backends key off to render the right per-operation views.

Content events

Prompt content and completion content are not span attributes (they would be too large and too sensitive). They're emitted as span events such as gen_ai.user.message, gen_ai.system.message, gen_ai.assistant.message, gen_ai.tool.message, and gen_ai.choice. Each event carries the message role and content as structured fields.

Content capture is gated behind a flag (OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT) so regulated workloads can disable it without losing the structural traces.

Why trace format is the load-bearing decision

The leading conformant instrumentation libraries

Why LangSmith is the proprietary outlier

Situations where this technique stops working.

2–4 min · Everything important, quickly.

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.

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 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.

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?

Add OpenInference's LangChain instrumentor, point its exporter at your OTel collector, run both LangSmith and OTel in parallel for validation, then disable LangSmith default callbacks once the OTel traces are validated.

2 more follow-ups an interviewer would ask next. Sign in to reveal them.

Red flags & common mistakes

The phrases 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 bullets to scan on the way to the call.

What the GenAI conventions standardise (attribute names + operations + events)
Five specific gen_ai.* attributes and what they carry

Primary sources. Browse if you want the original framing.