OpenTelemetry GenAI Conventions: A Common Vocabulary for AI Observability

OpenTelemetry is giving GenAI systems a shared telemetry vocabulary, but it is not a finished universal schema. In June 2026, the project moved its GenAI, provider-specific, and MCP semantic conventions into a dedicated repository so they could iterate and version independently. That repository currently marks the GenAI conventions as Development, and as of August 21, 2026 it has no official release. The opportunity is still substantial: common names for model operations, token usage, agent steps, MCP calls, content events, and evaluation results can reduce translation work across instrumentation and observability backends. The engineering posture should be adoption with version awareness—not an assumption that gen_ai.* has already frozen.

Two teams can emit valid OpenTelemetry and still disagree about what an LLM call means. Transport interoperability and semantic interoperability are different problems. OTLP can move telemetry between systems; semantic conventions make the fields inside that telemetry more consistently interpretable. For GenAI, the second problem is still being actively standardized.

1. Why GenAI Needs More Than Generic APM

Generic APM remains useful for throughput, latency, errors, dependencies, and service health. GenAI adds semantics that those signals do not describe by themselves.

Probabilistic behavior. The same logical request can produce different outputs, so debugging often needs the requested and served model, generation settings, response identifiers, and—where policy permits—relevant input or output context. Full content is useful evidence, but it is not always appropriate or necessary to retain.

Token economics. Request counts still matter for load and rate limiting, but they are insufficient for spend and model-efficiency analysis. A small number of long-context calls can cost more than a large number of short ones. Current GenAI metrics include token usage and operation duration, along with time-to-first-chunk and time-per-output-chunk measures.

Agent structure. A model call is only one operation inside many agents. Planning, tool execution, retrieval, workflows, and MCP calls may determine the outcome. Observability therefore needs a vocabulary for the execution that surrounds inference, not only the provider API boundary.

Content sensitivity. Prompts and outputs frequently contain user or business data. OpenTelemetry can describe how to record that content, but whether to capture, retain, export, redact, or restrict it remains a data-governance decision.

2. What the Conventions Cover Now

The most useful way to read the current work is by signal and operation rather than by assuming one maturity ladder. The dedicated GenAI repository marks the overall conventions as Development.

Model and inference spans. Current conventions define GenAI client operations including inference, embeddings, retrievals, response fetching, memory operations, and tool execution. Common attributes include gen_ai.provider.name, gen_ai.operation.name, requested and response model identifiers, and input/output token usage. Span timing supplies operation duration; dedicated metrics standardize token usage and latency-related measurements.

Agent and framework spans. The agent conventions define operations such as create_agent, invoke_agent, invoke_workflow, plan, and execute_tool. These spans can make an instrumented execution path reconstructible. They do not expose a model's private reasoning, and they do not appear automatically unless the relevant framework or instrumentation emits them.

MCP conventions. MCP has its own Development conventions for client and server spans, W3C Trace Context propagation, transport correlation, tool-aware attributes, and metrics such as mcp.client.operation.duration and mcp.server.operation.duration. The value is continuity across the MCP boundary—not a promise that every MCP implementation already emits the conventions.

Metrics and provider-specific conventions. The repository defines client, server, workflow, agent, and tool metrics and adds provider-specific conventions for systems including OpenAI, Anthropic, Azure AI Inference, and AWS Bedrock.

3. Content Capture Is an Opt-In Policy Decision

The current event gen_ai.client.inference.operation.details can carry chat history, parameters, inputs, and outputs independently from the main trace. Its requirement level is explicitly Opt-In, and the OpenTelemetry documentation warns that event support is not yet available in every language.

That is a better default than treating prompts and completions as ordinary diagnostic text. OpenTelemetry defines the telemetry shape; it does not decide your retention period, regional storage, access policy, legal basis, or redaction requirements. Those remain operator and backend responsibilities.

For a production deployment, write the policy before turning content on: which environments may capture full content, what is filtered or truncated, where exported telemetry is allowed to go, how long it is retained, and who can retrieve it.

4. What This Means for a Gateway

A gateway is a strong emission point for the model traffic that actually passes through it. It observes requested and served models, latency, provider outcomes, token usage, routing behavior, and cost inputs without asking every application team to rebuild that collection independently. It is not, by itself, a complete agent trace: app-local planning, retrieval, tool work, or calls that bypass the gateway require instrumentation at those layers.

TrueFoundry already exports over OpenTelemetry. AI Gateway supports OTLP export for traces and metrics to compatible observability platforms. TrueFoundry's current engineering material also documents provider spans using contemporary attributes such as gen_ai.provider.name, gen_ai.operation.name, gen_ai.request.model, gen_ai.response.model, gen_ai.usage.input_tokens, and gen_ai.usage.output_tokens, alongside TrueFoundry-specific extensions for gateway context and cost. (OpenTelemetry export docs; TrueFoundry's gateway instrumentation guide.)

MCP visibility can live in the same operational plane. TrueFoundry's Metrics Dashboard tracks MCP traffic, servers, tools, failures, and latency for calls routed through the AI/MCP Gateway. That complements—not replaces—application or harness instrumentation for agent-local steps. (Metrics Dashboard; MCP Gateway overview.)

The agent runtime is the complementary observability boundary. TrueForge, TrueFoundry's open-source agent harness, runs the model/tool loop with MCP tools, skills, sandboxing, approvals, context management, and persistent sessions. Its SDK model exposes an explicit Agent → Session → Turn → Event hierarchy, with streamed events for MCP initialization, model messages, tool responses, approvals, and turn completion. Those runtime events carry agent-level context that a gateway cannot infer from model and MCP traffic alone.

The publication-safe claim is deliberately narrower than an integration claim: this article does not assert that TrueForge currently emits the latest OpenTelemetry GenAI semantic conventions. Instead, TrueForge provides an open, inspectable runtime surface that can be instrumented or correlated with the OTLP traces TrueFoundry AI Gateway already exports. That separation is useful architecture: the harness knows what the agent is doing; the gateway knows what crossed its policy boundary; OpenTelemetry gives those instrumented layers a common transport and increasingly common vocabulary.

External trace export has an explicit content control. TrueFoundry's OTel integration guides document an Exclude Request Data option that removes tfy.input, tfy.output, and tfy.input_short_hand from exported spans while retaining structural telemetry such as tokens, latency, and model metadata. That is a useful egress control for those TrueFoundry content fields; teams should still review any additional standard or custom attributes they emit. (example integration documentation.)

Evaluation stays a separate computation. TrueFoundry supports external evaluation workflows over traces, while the OpenTelemetry convention provides a standard place to represent an evaluator's result. Do not collapse those into one claim: telemetry carries evidence; evaluators interpret it. (online evaluation.)

5. A Deployable Posture

Separate OTLP portability from semantic-convention maturity. It is useful to export traces and metrics over OpenTelemetry today even while GenAI field names continue to evolve.

Pin and test the semantics you actually emit. The GenAI repository is Development, older core definitions have moved, and language support is uneven. Treat your emitted attribute set as a versioned interface and test it against the backend and instrumentation libraries you operate.

Instrument each enforcement or execution boundary for what it can actually see. A gateway is excellent for model and gateway-routed MCP traffic. Agent/harness instrumentation is still needed for planning, local tools, retrieval, state transitions, and other work that never crosses that gateway.

Instrument the harness boundary when you need agent semantics. If you use TrueForge, its session, turn, and event model gives you explicit runtime identifiers and tool/approval events to correlate with gateway traces. Carry only the correlation metadata your observability policy permits; do not copy sensitive event payloads into span attributes by default.

Make content capture opt-in by policy. Minimize and filter content before export, then set retention and access controls in the observability backend. Do not confuse an OpenTelemetry field name with a data-governance policy.

Keep evaluation separate, but correlate it. Compute quality or safety with the evaluator appropriate to the workload, then use a standard evaluation-result event where supported to attach the outcome to the operation that produced the response.

Use custom attributes as extensions, not replacements. Product-specific fields such as TrueFoundry's gateway and cost metadata are useful. Keep the standard attributes alongside them so generic tooling still has a common surface.

6. Where the Standard Stops

The semantic conventions solve a vocabulary problem, not every observability problem. The dedicated OpenTelemetry GenAI repository is still Development; implementation coverage varies by language and library; and backends can differ in how they index, query, render, retain, or price the same telemetry. Even perfect semantic-convention coverage only describes what the instrumentation can observe—it does not expose hidden model reasoning or make uninstrumented execution visible.

For TrueFoundry, the useful claim is concrete: AI Gateway can export traces and metrics over OTLP and documents current-style gen_ai.* attributes alongside TrueFoundry-specific extensions. That gives teams a standards-based export path without pretending the independently evolving GenAI conventions are frozen. If a particular semantic-convention version is a procurement or governance requirement, validate the exact emitted attribute set and language/backend support you depend on.

References

• OpenTelemetry — GenAI semantic conventions overview (current status: Development).
• OpenTelemetry — GenAI client spans, metrics, and agent/framework spans.
• OpenTelemetry — MCP semantic conventions for client/server spans, propagation, and metrics.
• OpenTelemetry — GenAI events, including opt-in inference details and gen_ai.evaluation.result.
• OpenTelemetry — core semantic-conventions v1.42.0, which moved GenAI definitions to the dedicated repository.
• TrueFoundry — OpenTelemetry trace and metrics export; AI Gateway instrumentation guide; Metrics Dashboard; MCP Gateway overview.
• TrueFoundry — online evaluation, as a separate computation over observability evidence.
• TrueForge — agent harness overview and SDK concepts, documenting the Agent → Session → Turn → Event hierarchy and runtime events for model, MCP, tool, approval, and completion activity. This post does not claim native conformance of those events to the latest GenAI semantic conventions.

OpenTelemetry GenAI status and field names are described from the current dedicated GenAI semantic-conventions repository as checked on August 21, 2026. The repository is Development and has no official release at that date. TrueFoundry product statements are limited to current public documentation and engineering material: OTLP export, gateway observability, MCP metrics, documented gen_ai.* attributes, and export-time filtering of specified tfy.* content fields. This post does not claim conformance to a particular unreleased OpenTelemetry GenAI repository commit.