Arize AX adds native support for OpenTelemetry GenAI semantic conventions

Co-Authored by Chris Cooning, Head of Product Marketing & Dheeraj Bandaru, Product Manager.

If your framework or managed agent platform already emits OpenTelemetry gen_ai.* spans, you shouldn’t need to maintain a custom processor just to make those traces useful.

Arize AX now natively supports OpenTelemetry GenAI semantic conventions, giving teams first-class observability for applications and agents that emit gen_ai.* telemetry. When compatible spans reach Arize AX, it normalizes supported attributes through a GenAI-to-OpenInference mapping. Span kinds, model and provider information, messages, token usage, tool inputs and outputs, and retrieved documents appear as structured AI trace data.

For platforms that already emit OpenTelemetry GenAI spans, including Microsoft Agent Framework and CrewAI Studio, you can send telemetry directly to Arize AX over OTLP, then inspect traces, run evaluations, and analyze token usage without reshaping attributes in client code.

What are OpenTelemetry GenAI semantic conventions?

OpenTelemetry GenAI semantic conventions are a shared vocabulary for describing generative AI operations and data in telemetry.

OpenTelemetry provides an open standard for collecting and transporting telemetry. Its GenAI conventions define common attribute names for model requests, agent and workflow invocations, tool calls, messages, retrieval, model metadata, and token usage.

These conventions make traces portable and understandable across services. Instead of every framework using different names for the same concept, a shared gen_ai.* vocabulary gives instrumentation libraries and observability platforms a consistent structure to interpret.

What changed in Arize AX?

Arize AX now maps supported gen_ai. attributes into first-class OpenInference fields during ingestion. Previously, these attributes could arrive in AX as raw custom fields, which meant evaluations, cost analysis, and debugging workflows might not recognize important context.

For example:

• gen_ai.operation.name helps classify LLM, embedding, tool, retriever, agent, and chain spans.
• gen_ai.input.messages and gen_ai.output.messages become structured input and output messages.
• gen_ai.usage.input_tokens and gen_ai.usage.output_tokens become prompt, completion, and total token counts.
• Provider, model, request parameters, tool calls, tool results, and retrieved documents map into their corresponding OpenInference fields.

After normalization, developers can:

• Inspect model interactions with recognized inputs and outputs
• Follow agent, workflow, retrieval, and tool behavior across a trace
• Run evaluations on structured data instead of raw custom attributes
• Analyze token consumption and model costs without maintaining a separate translation layer

What happens to the original attributes?

AX also preserves the original gen_ai.* attributes on the span. If an explicit OpenInference attribute is already present, it takes precedence. If AX cannot confidently classify an operation, it leaves the span kind unset rather than guessing.

When should I use OpenTelemetry GenAI conventions or OpenInference?

Both conventions solve the same interoperability problem from two different starting points.

Arize created OpenInference because AI applications needed dependable semantic conventions before the broader OpenTelemetry GenAI standard was mature enough to provide them.

Early GenAI conventions changed frequently at the attribute level. OpenInference provided an open-source, opinionated layer with stable attribute names, rich AI-specific coverage, and auto-instrumentors for popular models and frameworks. Meanwhile, more frameworks and managed platforms emit gen_ai. telemetry natively.

In practice, you should:

• Use OpenInference when you control application instrumentation and want an established AI-specific schema with auto-instrumentation
• Use OpenTelemetry GenAI semantic conventions when a framework or platform already emits gen_ai. spans, or when you only control OTLP export.
• Use both across mixed environments. Arize AX keeps existing OpenInference traces intact and normalizes compatible GenAI spans at ingestion.

Why does this matter for managed and low-code agents?

It removes the need to install a conversion processor in a runtime you don’t control.

Users of managed or low-code agent platforms often control an OpenTelemetry endpoint but not the platform’s runtime or instrumentation code. That made a client-side conversion processor impractical or impossible to add.

With native support, compatible spans can be routed directly to Arize AX and normalized at ingestion. Developers and enterprise AI platform teams can observe custom services and platform-built agents in the same project with consistent trace fields.

How do I send OpenTelemetry GenAI traces to Arize AX?

1. Configure your framework or platform’s OTLP exporter with your Arize AX endpoint, Space ID, API key, and project name.
2. Send compatible spans that use supported gen_ai.* attributes.
3. Open the traces in Arize AX and confirm that span kinds, messages, token counts, tool calls, and retrieval data appear in their structured fields.

Do I need a client-side conversion processor?

No. Arize AX performs the supported GenAI-to-OpenInference mapping during ingestion, so no client-side reshape processor is required.

Next steps

Read the OpenTelemetry GenAI semantic conventions overview, review the full attribute and span-kind mapping, or get started with Arize AX.

Native OpenTelemetry GenAI support let teams use the telemetry their frameworks already emit while keeping the same Arize AX workflows for debugging, evaluation, token analysis, and cost analysis.