What Is OpenTelemetry for AI Agents?

OpenTelemetry, usually shortened to OTel, is a vendor-neutral set of APIs, SDKs, conventions, and protocols for producing telemetry.

For an agent system, it gives planners, models, tools, and services a shared way to describe their work without tying instrumentation to one observability vendor.

The four pieces people often confuse

Instrumentation

Instrumentation is the code that creates spans and attaches attributes or events. It may be written manually or provided by a framework integration.

The OpenTelemetry SDK

The SDK samples, processes, and exports the telemetry created by instrumentation. It also attaches resource information such as service name, environment, and build identity.

OTLP

The OpenTelemetry Protocol, or OTLP, transports telemetry. OTLP can encode traces as protobuf or JSON and send them over HTTP. OTLP is the delivery mechanism, not the trace itself.

The Collector

The OpenTelemetry Collector is an optional process that receives, processes, and routes telemetry. An application can also send OTLP directly to a compatible backend.

Agent instrumentation
→ OpenTelemetry SDK
→ OTLP/HTTP
→ Collector or trace backend
→ storage and analysis

What OpenTelemetry standardizes

OpenTelemetry gives every span a common structural foundation:

• trace and span identifiers;
• parent relationships;
• nanosecond timestamps;
• span kind and status;
• typed attributes;
• events;
• links;
• resource and instrumentation-scope metadata.

Semantic conventions add agreed names for common concepts. Generative AI conventions can describe model requests, token usage, operations, and agent-related fields.

What it does not standardize completely

OpenTelemetry does not make every agent framework produce identical traces.

Different libraries may disagree about:

• where a logical run begins;
• whether a tool call is a child span or an event;
• how agent roles are represented;
• where prompts and outputs are stored;
• how retries and handoffs are connected;
• which generative AI convention version they follow.

Trace analysis still needs normalization and explicit telemetry-gap reporting. A backend should not silently invent missing semantics from a span name.

A minimal agent trace

Suppose order_replacement is instrumented as a tool span. Useful fields might include:

span.name                  = "order_replacement"
span.status                = ERROR
agent.role                 = "card_support"
gen_ai.tool.name           = "order_replacement"
agent.operation            = "order_replacement"
agent.tool.requirement     = "required"
agent.tool.status          = "failed"
tool.result.success        = false
service.version            = "support-agent-2.4.1"
deployment.environment.name = "staging"

Those fields make the tool outcome and requiredness explicit. If the operation mutates state, also record effect, retry safety, a state predicate, and the observed state. The public uncertain-mutation fixture shows why a timeout without those facts cannot safely be reduced to “failed.”

Why vendor-neutral instrumentation matters

Your agent should not need to know whether its traces will be inspected in a local desktop application, routed through a collector, or sent to a hosted platform.

OTLP creates a useful boundary:

Instrument once
→ choose where traces go
→ change the destination without rewriting the agent

That is why local tools can receive the same telemetry that production observability systems use.

OpenTelemetry is the evidence layer

OpenTelemetry does not decide whether the replacement-card response was acceptable. It gives you the structured evidence needed to make that decision.

The next lesson separates logs, traces, findings, and evals, which are related but not interchangeable.