OpenInference vs. OpenTelemetry GenAI Conventions: Which Should You Use for Agent Tracing?

When teams set up observability for AI agents, they usually focus on two decisions: which tracing library to instrument with, and which backend to send traces to. There's a third decision sitting underneath both, and it shapes how useful your traces actually are. That decision is the semantic convention.

A semantic convention is the schema that defines how agent behavior gets encoded into spans: what an LLM call looks like, how a retrieval step is represented, how a tool invocation is labeled. Pick the wrong one and your traces will be missing the exact details you need when an agent misbehaves in production. Two conventions dominate the conversation today: the OpenTelemetry GenAI semantic conventions and OpenInference. This post defines both, compares them across the axes that matter for agents, and offers guidance on when each makes sense.

What a Semantic Convention Is (and Why It Matters for Agents)

OpenTelemetry has become the standard for vendor-neutral observability. Its biggest advantage is portability: you instrument your code once and emit traces that any compatible backend can ingest, without re-instrumenting when you switch tools. That matters for agents, which rarely live in isolation. A single agent execution can span services, APIs, databases, and other agents. OpenTelemetry's distributed tracing model lets you follow that execution end to end, even as it crosses system boundaries.

A semantic convention is the agreed-upon vocabulary layered on top of that tracing model. It defines the span types, attribute names, and structures that describe what your agent did. Without a shared convention, every team would encode prompts, completions, and tool calls differently, and no backend could reliably interpret them. With one, traces become portable and legible across the ecosystem.

Both conventions discussed here live inside OpenTelemetry. The question is not whether to use OpenTelemetry. It's which semantic convention you adopt to describe agent behavior within it.

Defining Both Standards Plainly

OpenTelemetry GenAI semantic conventions are the OTEL community's standard for representing generative AI and LLM operations in spans. They define attributes under the gen_ai.* namespace, covering model requests, responses, token usage, and related metadata. As part of the broader OpenTelemetry project, they carry the weight of a large, well-governed community and a clear trajectory toward becoming the ecosystem default for GenAI telemetry.

OpenInference is an open-source semantic convention purpose-built for LLM and agent workloads. It was designed from the start around the specific shapes of agentic systems: LLM calls with full prompt and completion detail, retrieval steps, re-ranking, tool calls, and multi-step chains. It has an active open-source community and iterates quickly, with broad auto-instrumentation support across popular frameworks.

Both are open. Both run on OpenTelemetry. The difference is in expressiveness and how much LLM-specific detail each captures out of the box today.

Side-by-Side Comparison

Richness of LLM Call Detail

The most common reason to trace an agent is to understand why it produced a given output. That requires capturing the full context of every LLM call: the prompt, the completion, token counts, cost, and model parameters like temperature and model name.

OpenInference captures this detail by default. Prompts and completions are recorded with explicit message typing (system, user, assistant, and tool), and token, cost, and model-parameter metadata come along for the ride. The OTEL GenAI conventions cover model requests, responses, and token usage through gen_ai.* attributes, and are steadily expanding, but today they capture less of this LLM-specific detail out of the box. When you compare traces from the same agent side by side, the OpenInference version is typically more complete and easier to debug.

First-Class Retrieval and Re-Ranking Spans

Agents often take wrong actions because they had bad context. Tracing retrieval lets you see exactly which documents were pulled, which were not, and why the model acted on what it received. This is one of the most common root causes of agent failures, and it's frequently invisible at the agent level because the agent confidently generates a response from whatever context it got.

OpenInference provides first-class support for retrieval and re-ranking spans, with explicit document types. For RAG-heavy agents, this is the difference between diagnosing a retrieval problem quickly and guessing at it. The OTEL GenAI conventions do not yet offer the same first-class retrieval modeling, so retrieval logic often ends up captured under generic span types that carry less structure.

Span-Type Granularity

When you read a trace, the span types tell you what kind of work each step represents. Granular, well-named span types make a complex agent execution legible at a glance.

OpenInference distinguishes between span types like LLM, TOOL, AGENT, CHAIN, and RETRIEVER, with explicit sub-types for messages, documents, tools, and tool calls. That granularity maps cleanly onto how modern agents are actually built. The OTEL GenAI conventions provide less differentiation between these distinct operation types today, which means more of your agent's structure collapses into generic spans that require interpretation.

Out-of-the-Box Auto-Instrumentation

The fastest way to get good traces is to use a framework with auto-instrumentation, so you don't have to manually annotate every LLM call and tool invocation.

OpenInference ships out-of-the-box auto-instrumentation for popular LLM frameworks, including LangChain, LlamaIndex, OpenAI, Google ADK, Mastra, AWS Strands, and CrewAI. Adding tracing to a framework like Google ADK can be as simple as a few lines of Python. The OTEL GenAI conventions have growing instrumentation coverage as the community expands them, but OpenInference currently offers broader, more mature out-of-the-box support across these agent frameworks.

Summary Comparison

Why Arthur Built on OpenInference

When building the Arthur platform, we chose OpenInference for production agent workloads. The reasoning came down to expressiveness where it matters most:

• Richer semantic detail for LLM calls, including full prompt and completion content, token counts, cost, and model parameters
• First-class retrieval and re-ranking spans, which are critical for RAG-heavy agents
• Clear distinctions between span types (LLM, TOOL, AGENT, CHAIN, RETRIEVER) and explicit types for messages, documents, tools, and tool calls
• Out-of-the-box auto-instrumentation for the frameworks teams actually build on
• An active open-source community that iterates quickly

The benefit extends beyond the trace viewer. Because OpenInference structures every retrieval call, tool invocation, and agent decision in a consistent, expressive way, that data feeds downstream into evaluations, experiments, and governance views without extra plumbing. A trace that captures the right detail at the source becomes the foundation for catching hallucinations, replaying production failures against new prompt versions, and giving compliance teams visibility into what an agent can actually do.

Where OTEL GenAI Is Catching Up

This is not a case of one standard being obsolete. The OpenTelemetry GenAI conventions are backed by a large, well-governed community and are on a clear path to becoming the broad ecosystem default for GenAI telemetry. They benefit from OpenTelemetry's maturity, its enormous contributor base, and its deep integration across non-LLM observability.

The conventions are expanding steadily, and the gap with OpenInference is narrowing. For teams that want to standardize telemetry across their entire stack, not just the LLM-specific parts, betting on the community-default trajectory is a reasonable position. The honest assessment today is that OTEL GenAI is still catching up on the expressiveness that LLM and agent workloads demand, particularly around retrieval spans and span-type granularity.

When Each Makes Sense

Choose the OpenTelemetry GenAI conventions if you are standardizing telemetry broadly across a large stack that includes plenty of non-LLM services, you want to bet on the community-default trajectory, and your agents are relatively simple in their retrieval and tool-use patterns.

Choose OpenInference if you are building production agents today, your workloads are RAG-heavy, and you need debuggable, LLM-specific detail right now: full prompt and completion capture, first-class retrieval spans, granular span types, and broad auto-instrumentation across LangChain, LlamaIndex, OpenAI, Google ADK, Mastra, AWS Strands, and CrewAI.

The reassuring part: because both conventions run on OpenTelemetry, you stay portable either way. You emit traces once and choose any compatible backend without re-instrumenting. The convention you pick shapes how much your traces tell you, not whether you're locked in.

TLDR

• A semantic convention is the schema that encodes agent behavior into spans. It sits underneath your tracing library and backend, and it determines how useful your traces are.
• Both OpenInference and the OpenTelemetry GenAI conventions run on OpenTelemetry, so both keep you portable across backends.
• OpenInference offers richer LLM call detail, first-class retrieval and re-ranking spans, more granular span types (LLM, TOOL, AGENT, CHAIN, RETRIEVER), and broader out-of-the-box auto-instrumentation today.
• The OTEL GenAI conventions are community-backed, well-governed, and catching up fast, making them a reasonable bet for broad, stack-wide standardization.
• Arthur built on OpenInference because expressive traces at the source feed directly into evals, experiments, and governance.

If you're setting up tracing for a production agent, the convention you choose is worth a deliberate decision rather than a default. To see how OpenInference-native tracing feeds the rest of the agent development lifecycle, explore the Agent Development Toolkit or book a demo with an AI expert.

‍