GenAI Observability in OpenTelemetry: Where the Standard Actually Stands in 2026

If your team is shipping anything that calls an LLM, you have probably already hit the wall this post is about. An agent takes 45 seconds to answer a simple question, and nobody can say whether it was the model, a slow tool call, or a retry loop. The traces you rely on for microservices tell you the HTTP request succeeded, and nothing about what the model actually did. Many of us are now operating production AI systems with less visibility than we'd accept from a basic CRUD service, and that gap is starting to hurt.

Here's the bottom line. OpenTelemetry's GenAI semantic conventions have matured into the de facto vocabulary for AI observability, and every major vendor now speaks it. The spec is still in Development status, though, which means you should adopt it today while expecting attribute names to shift before it locks. Instrumenting now buys you a vendor-neutral foundation. Waiting for "stable" buys you nothing but lost visibility.

This post covers three things, in order: how the conventions got here and what the six layers actually define, the specific attributes and metrics you should be emitting right now, and the state of vendor and framework adoption, including what's solid and what's still moving.

Part one: how we got here and what the spec covers

OpenTelemetry formed the Generative AI Special Interest Group (the GenAI SIG) in April 2024, under the existing Semantic Conventions SIG. The original scope was modest: define a standard set of attributes for LLM client calls, model name, token usage, latency, so that different instrumentation libraries would stop inventing their own incompatible vocabularies.

That scope has expanded considerably. As of mid-2026 the conventions span six distinct layers:

1. Client spans — the base layer, covering a single call to a model or service.
2. Agent and workflow spans — agent invocation, creation, and orchestration above the single-call level.
3. MCP conventions — tracing Model Context Protocol tool calls so a single trace links the agent's decision through the tool server's execution and back.
4. Events — structured capture of prompt and completion content, kept separate from spans by design.
5. Metrics — the histograms for latency and token usage.
6. Provider conventions — provider-specific attribute flavors for OpenAI, AWS Bedrock, and others.

The turning point was release v1.37. Before it, chat history was recorded as one event per message, which flooded multi-turn conversations with fine-grained events that were painful to query and correlate. v1.37 replaced that with three aggregated attributes, gen_ai.system_instructions, gen_ai.input.messages, and gen_ai.output.messages, that can sit on the span itself or on a new inference-details event. If you instrumented early and your dashboards suddenly looked different, this is why.

One structural change is worth flagging for anyone tracking the spec. As of the v1.41 line, all gen_ai.* attributes, metrics, events, and spans were deprecated in the core semantic-conventions repository and moved to a dedicated GenAI repository (semantic-conventions-genai). The content didn't change; the home did. If you have bookmarks or automation pointing at the old paths, update them.

The honest status, as of this writing, is that the GenAI and MCP conventions remain in Development, not Stable. Nearly every gen_ai.* attribute still carries a Development stability badge, which means names can change without a major version bump. The spec ships an escape hatch for this: the OTEL_SEMCONV_STABILITY_OPT_IN environment variable. Setting it to gen_ai_latest_experimental emits the newest experimental conventions; leaving it unset keeps your instrumentation on whatever version it already emitted (v1.36 or prior is the transition baseline). This lets you migrate on your own schedule instead of having a release yank attribute names out from under you.

Part two: what to actually emit

Here is the concrete part, the attributes and metrics that earn their place in production.

The core span attributes. Every model call should produce a CLIENT-kind span (it usually crosses a process boundary to a remote service). The key attributes:

• gen_ai.operation.name — chat, text_completion, or generate_content for multimodal.
• gen_ai.provider.name — the telemetry "flavor," e.g. openai, anthropic, aws.bedrock. This acts as a discriminator: a Bedrock span carries aws.bedrock.* attributes, not openai.* ones.
• gen_ai.request.model — the exact model name requested.
• gen_ai.usage.input_tokens and gen_ai.usage.output_tokens — the token counts.
• gen_ai.response.finish_reasons — why generation stopped (stop, tool_calls, and so on).
• gen_ai.conversation.id — added to tie multi-turn sessions together.

The span name follows the pattern {operation.name} {model}, for example chat anthropic, which keeps traces human-readable in any backend.

The two metrics you cannot skip. Two histograms are effectively mandatory for any production deployment:

• gen_ai.client.operation.duration — call latency, in seconds.
• gen_ai.client.token.usage — consumption in tokens, broken down by gen_ai.token.type into input and output.

Those two signals are the floor. Without them you cannot reason about either cost or speed, and in an LLM system, cost and latency both correlate with token counts rather than request counts, so this is not optional accounting. These two metrics are what let you estimate per-request cost, catch a token-hungry prompt before it reaches production, and spot a latency regression.

Content goes in events, not attributes. This is the design decision teams most often get wrong. Storing full prompt and completion text in span attributes is an anti-pattern: attributes are always indexed, they have size limits, and they expose any PII straight into your backend. The conventions deliberately put content into span events instead, which can be filtered or dropped at the Collector level without touching application code.

By default, no prompt content or tool arguments are captured at all, only metadata like model names, token counts, and durations. You opt into content capture explicitly (the relevant SDK flag is OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT). Before you flip that on in production, the practical guidance is defense in depth across three layers: keep capture off unless you need it, configure the Collector's redaction and transform processors to scrub anything sensitive that does leak through, and lock down access to the trace backend so the blast radius stays small if redaction misses something. Assume each layer will fail at least once, and you'll size your controls correctly.

The overhead concern comes up in every review, so it's worth answering directly. Instrumentation adds well under a millisecond per span, and because OpenTelemetry uses asynchronous batch processing, the hit to your main application is under 1%. LLM API latency, anywhere from 100ms to 30 seconds, dominates entirely. The real cost is telemetry storage volume, which you manage with sampling, not by skipping instrumentation.

Part three: who actually supports this

A standard is only as useful as its adoption, and this is where the analytical case for instrumenting now gets strong.

Backends and vendors. Datadog was among the first commercial platforms to natively support the v1.37+ GenAI conventions, letting teams instrument once with OTel and analyze spans in LLM Observability with no code changes. New Relic, Dynatrace, and Honeycomb now support the conventions natively as well, so OTel-instrumented agent code reaches these platforms without SDK changes. MLflow both ingests GenAI-semconv traces from any compliant tool and can export in the gen_ai.* format. Open-source backends including Grafana Tempo, Uptrace, OpenObserve, Jaeger, and GreptimeDB understand the conventions out of the box.

Frameworks and instrumentation. The OpenAI Python SDK instrumentation is the most mature path and the easiest place to start. From there, community libraries, OpenLLMetry (now folded into the official conventions) and OpenLIT, extend coverage to roughly 14 LLM providers including Anthropic, Cohere, Google, Groq, Bedrock, Mistral, and Ollama, plus seven vector databases. CrewAI ships native OpenTelemetry support, LangChain added native end-to-end OTel into its SDK, and framework instrumentation for LangGraph, AutoGen, and Semantic Kernel is in progress.

Even the coding assistants emit it now. VS Code Copilot emits traces, metrics, and events for every agent interaction. OpenAI Codex exports structured log events and OTel metrics for requests, tool calls, and sessions. Claude Code exports metrics and log events via OTel, with trace support in beta. If your developers run these tools, you can point them at any OTLP backend and watch the LLM calls in a trace viewer today.

The adoption curve. The numbers tell a consistent story of demand outpacing tooling. The Grafana 2026 Observability Survey, more than 1,300 practitioners across 76 countries, found that 14% currently use observability for LLM-based production workloads, up from 5% a year earlier, while the "not on my radar" cohort dropped from 42% to 29% in twelve months. Gartner projects LLM observability investment will reach 50% of GenAI deployments by 2028, up from roughly 15% today. The teams instrumenting now are buying an asymmetry: when an agent misbehaves, they answer "why" from a trace in minutes, while the uninstrumented majority re-runs and guesses.

The takeaway hasn't changed, but the evidence behind it has. OpenTelemetry's GenAI conventions are the vendor-neutral vocabulary the whole ecosystem is converging on, and the Development status is a reason to manage your migration carefully, not a reason to wait. Emit the two core metrics, put content in events behind the capture flag, and use the stability opt-in to control when attribute changes reach you.

For the engineers on your team, the practical promise is concrete: the next time an agent does something inexplicable in production, the difference between a five-minute trace lookup and an afternoon of re-running prompts is whether you instrumented before you needed to. That's the whole case for moving now.

We covered three things: how the conventions reached their current six-layer shape, the specific attributes and metrics worth emitting, and the state of adoption across vendors, frameworks, and tooling. The natural next step is the part of the spec that is still being argued out in the open, evaluation, agentic systems, and the conventions that don't exist yet.

Next in the series: the frontier of the GenAI conventions, where evaluation and agent semantics are still being defined.