OpenTelemetry graduated from the Cloud Native Computing Foundation on May 21, 2026, and the same schema that standardized traces for microservices is now the emerging standard for watching LLMs and agents run. The GenAI semantic conventions define a vendor-neutral vocabulary for every model call, tool execution, and agent step, so your telemetry reads the same whether the request went to OpenAI, Anthropic, or a model you host. For teams that run agents as production services, this decides whether observability data stays portable or gets locked inside one vendor's SDK.
Key takeaways
- OpenTelemetry graduated CNCF on May 21, 2026, backed by over 12,000 contributors from more than 2,800 companies, and ranks second in project velocity behind Kubernetes among 240+ CNCF projects (CNCF).
- The GenAI conventions live under the
gen_ai.*namespace and cover eight operation types, including chat, embeddings, invoke_agent, and execute_tool. - Token accounting is first-class:
gen_ai.usage.input_tokensandgen_ai.usage.output_tokens, plus cache-read and reasoning-token attributes, turn cost into a queryable metric. - MCP tool calls get their own spans and propagate W3C Trace Context, so one trace can span an agent, its model calls, and out-of-process tool servers.
- The conventions stay in Development status with no 1.0 and no stabilization date; attribute names still change, so pin the version.
- Vendors already emit compliant spans, including Claude Code, OpenAI Codex, and VS Code Copilot.
What Are OpenTelemetry's GenAI Semantic Conventions?
They're a shared schema that names the spans, attributes, metrics, and events an LLM or agent application should emit. Instead of every framework inventing its own field for the model name or the token count, the conventions fix those under one namespace, gen_ai.*, so traces from LangChain, the OpenAI SDK, or a homegrown agent describe the same operation the same way.
The schema sits inside OpenTelemetry's wider semantic conventions, the layer that already gives HTTP, database, and messaging spans a common vocabulary. A GenAI special interest group formed in 2024 to extend that discipline to model calls, and the scope has since grown to cover agent orchestration, MCP tool calling, content capture, and quality evaluation.
The payoff is concrete. Any backend that speaks OpenTelemetry, from Grafana to Datadog to an open-source collector, can read the data without a bespoke integration, which is the property that lets you change model providers or observability vendors without re-instrumenting your code.
Why Does a Telemetry Standard for AI Matter Now?
Because a GenAI system is a distributed system, and it inherits every latency, reliability, and cost problem that comes with one. "As organizations rush to put AI workloads into production, they are discovering that GenAI systems are distributed systems, with all the latency, reliability and cost questions that come with them," said Juraci Paixao Krohling, CEO of OllyGarden, in CNCF's graduation announcement.
Graduation is the signal that the substrate is stable enough to build on. OpenTelemetry drew over 12,000 contributors from more than 2,800 companies and trails only Kubernetes in project velocity across 240+ CNCF projects, with its JavaScript and Python APIs each downloaded more than 1.3 billion times in the past year. When a standard reaches that scale, betting your instrumentation on it stops being speculative.
The practical stakes are sharp. An agent that retries, calls three tools, and spends real money on every request needs the same answerability you expect from any service. Without a common schema, that data fragments across vendor SDKs, and you pay a migration tax each time you swap a model or a backend.
Which Spans, Attributes, and Metrics Does the Schema Define?
The schema keys every span to a gen_ai.operation.name that states what work it wraps, then attaches attributes describing the request, the response, and the cost. Eight operation names cover the common cases.
| Operation name | What the span wraps | Representative attributes |
|---|---|---|
chat | A chat-completion call | gen_ai.request.model, gen_ai.response.finish_reasons |
text_completion | A legacy text completion | gen_ai.request.model |
generate_content | A multimodal generation | gen_ai.input.messages |
embeddings | An embedding request | gen_ai.request.model |
create_agent | Agent construction | gen_ai.agent.name |
invoke_agent | One agent run | gen_ai.agent.name |
invoke_workflow | A multi-step workflow | gen_ai.agent.name |
execute_tool | One tool call | gen_ai.tool.name, gen_ai.tool.call.arguments |
Cost and provenance ride on standard attributes. gen_ai.provider.name records the backend (openai, anthropic, aws.bedrock), gen_ai.request.model and gen_ai.response.model capture what you asked for against what answered, and gen_ai.usage.input_tokens and gen_ai.usage.output_tokens make token spend a first-class field. Provider extensions add gen_ai.usage.cache_read.input_tokens and gen_ai.usage.reasoning.output_tokens, which matter once prompt caching and reasoning models drive your bill.
Two metrics anchor the numbers you'll alert on: gen_ai.client.operation.duration in seconds and gen_ai.client.token.usage counted in tokens. Prompt and completion content, when you choose to capture it, lands in events or in the gen_ai.input.messages and gen_ai.output.messages attributes, so it doesn't get forced onto every span by default.
How Does It Trace an Agent That Calls Tools Over MCP?
It nests them. An invoke_agent span becomes the parent, and each model call and each execute_tool span hangs beneath it, so one trace shows the full reason-and-act loop in order instead of as disconnected log lines.
Tool calls that cross a process boundary through the Model Context Protocol get first-class treatment. MCP client spans carry mcp.method.name, mcp.session.id, and mcp.protocol.version, and they propagate W3C Trace Context to the MCP server span on the other side. The result is a single trace that stitches an orchestrator to a tool server running in a different container or on a different host.
That end-to-end view is where the standard earns its keep. When an agent stalls, you can see whether the model deliberated, a tool timed out, or the handoff between them dropped context, which is the exact ambiguity that makes agent failures hard to diagnose. For why MCP became the interoperability layer these spans assume, see what MCP means for enterprise AI.
How Does It Compare to Langfuse, Arize, and Proprietary SDKs?
The conventions aren't a rival to those tools; they're the wire format the better ones now speak. The real choice sits between instrumenting against a vendor's proprietary SDK, emitting OpenTelemetry-native spans, or running a hybrid of both.
| Approach | How data is emitted | Portability | Main trade-off |
|---|---|---|---|
| Proprietary SDK | Vendor's own client library | Low, tied to one backend | Fastest to start, hardest to leave |
| OpenTelemetry-native | gen_ai.* spans via the OTel SDK | High, any OTLP backend | More manual instrumentation, experimental schema |
| Hybrid | OTel spans plus a vendor SDK for evals and UI | Medium | Two systems to maintain |
Most managed platforms, Langfuse, Arize, and Datadog among them, now ingest OTLP and map the gen_ai.* attributes onto their dashboards, so an OpenTelemetry-native pipeline keeps the analysis layer swappable. If you've already traced an app with a dedicated tool, see how that works in practice in tracing and debugging LLM apps with Langfuse. The rule of thumb: instrument once against the open schema, then treat the backend as a replaceable decision.
Is It Safe to Adopt While the Conventions Are Still Experimental?
Yes, with one discipline: pin the convention version and expect names to move. The GenAI and MCP conventions sit in Development status, there's no 1.0, and no public stabilization date, which means attributes can be renamed between releases. The rename of gen_ai.system to gen_ai.provider.name is the canonical example of churn you have to absorb.
The countervailing signal is adoption. Claude Code, OpenAI Codex, and VS Code Copilot already emit compliant spans, and major frameworks emit them natively, so the schema gets pressure-tested at scale before it freezes. OpenTelemetry's graduation as a foundation makes fast stabilization more likely, and the OTel Collector's declarative configuration is already stable, so the pipeline underneath the schema is solid.
The honest posture, echoed across the practitioner write-ups, is to adopt now behind a pinned version and budget for a migration or two before 1.0. That's a smaller cost than staying on a proprietary format you'll have to unwind later.
What Should Engineering Leaders Do About It Now?
Treat GenAI instrumentation as a platform decision, not a per-project one. Standardize on the OpenTelemetry SDK for new agent and LLM services, route everything through a single Collector, and pin the semantic-convention version in one place so upgrades stay deliberate.
Three calls deserve explicit ownership:
- Content capture.
gen_ai.input.messagesandgen_ai.output.messageshold raw prompts and completions, which means PII and storage cost. Decide per service whether to capture full content, redact it, or sample it, and make that a policy rather than a default. - Cost as a metric. Wire
gen_ai.client.token.usageinto the same dashboards as latency so token spend stays visible per model, per route, and per tenant from day one. - Evaluation signals. The
gen_ai.evaluation.resultevent carries a score value and label, giving you a standard place to land quality checks next to traces. It's newer and thinner than the tracing attributes, so confirm your backend renders it before you depend on it.
Reliability work compounds on top of this. Once traces and token metrics are standardized, the harder question is what "reliable" even means for an agent, which is a measurement problem of its own; measuring agent reliability beyond pass@1 is where that goes next.
What to Watch as the Conventions Mature
Three fault lines decide how much rework you're signing up for. Schema churn is the obvious one: until a 1.0, each upgrade can rename attributes, so teams that centralize their convention version absorb it cheaply while teams that scatter hard-coded field names do not.
Cardinality and cost are the quieter risk. Storing full gen_ai.input.messages on high-traffic agents can dwarf your normal trace volume, and message content resists the sampling tricks that keep ordinary tracing affordable. Plan for content capture to be selective, not universal.
The last fault line is the evaluation and agent-memory surface. The tracing and token attributes are mature enough to build on; the evaluation events and the proposed agent-application conventions for tasks, actions, and memory are still forming. Instrument against them if you want a head start, but keep them behind a flag until they settle.
Sources
- OpenTelemetry GenAI semantic conventions: spans
- OpenTelemetry semantic conventions repository (gen-ai)
- CNCF: OpenTelemetry graduation announcement
- OpenTelemetry is a CNCF Graduated Project
- Greptime: How OpenTelemetry traces LLM calls, agent reasoning, and MCP tools
- CNCF: OpenTelemetry has graduated, now what?