OpenTelemetry for AI agents is the use of OpenTelemetry’s vendor-neutral traces, metrics and logs, together with its GenAI semantic conventions, to instrument every step of an agent run rather than only its model calls. Done well, it gives teams portable telemetry about agents, tools and costs that any compatible backend can analyze.
Where the standard stands
OpenTelemetry’s GenAI semantic conventions define how model calls, agent invocations and tool executions should be named and described. They also include conventions for Model Context Protocol calls. The important caveat is status: these conventions are marked as being in Development, which means attribute and span names can still change. The conventions themselves advise that instrumentations already emitting an earlier version should not change what they emit by default, and that newer versions should be enabled through an explicit opt-in. In practice, pin the version you use, test upgrades, and check which version your backend expects. Datadog’s documentation, for example, specifies version 1.37 or later of the GenAI conventions for ingesting OpenTelemetry traces.
What to instrument beyond LLM calls
What to capture | Why it matters | Source |
Agent invocation | Defines the run and its boundaries | GenAI conventions (agent spans) |
Model calls | Latency, model, token usage | GenAI conventions |
Tool execution | Which tool, with what outcome and duration | GenAI conventions (tool execution) |
MCP calls | Tool identity and protocol details across the boundary | MCP conventions (Development) |
Session or conversation identifier | Links turns of one conversation | Convention-supported attribute added by the application |
Errors | Low-cardinality error type for aggregation | General error conventions |
Retrieval and memory steps | Explains what context the agent had | Instrumentation-specific or custom attributes |
Guardrail and policy decisions | Shows why an action was blocked or allowed | Custom attributes under your own namespace |
Human approvals | Records who approved an action and when | Custom attributes under your own namespace |
Business outcome | Connects behavior to results | Custom attributes under your own namespace |
Practical guidance
Keep span names stable and low in cardinality. Put variable values in attributes, not in span names, so that aggregation works.
Treat content as sensitive. Prompt and completion content, and tool definitions, are opt-in in the conventions for good reason. Decide what to capture, mask what must be masked, and store it where your policy allows.
Propagate context everywhere. An agent run often crosses services, tools and MCP servers. Without context propagation, the trace breaks exactly where the interesting failures occur.
Sample with care. Uniform sampling can discard the rare runs that matter most. Prefer keeping complete traces for failed, slow and expensive runs.
Add custom attributes deliberately. For policy decisions, approvals and business outcomes, define your own namespace and document it, so that the attributes survive changes to the standard.
Why this matters for portability
Because the telemetry follows an open standard, it can be sent to any backend that accepts OTLP, and major observability vendors, including Datadog and Dynatrace, document ingestion of OpenTelemetry-based GenAI telemetry. That makes vendor choice reversible, which is the practical meaning of avoiding lock-in. The condition is discipline: use the standard attributes where they exist, and keep custom attributes separate and documented.
Where Bonree ONE fits
Bonree ONE is built on a native OpenTelemetry architecture, and Bonree ONE AI Observability traces agents built on LangChain, LangGraph, Dify and OpenClaw, with call chain, session and token views. Teams that standardize their instrumentation on OpenTelemetry keep the freedom to change platforms later, while the platform provides the correlation with application and infrastructure data.
FAQ
Are OpenTelemetry’s GenAI conventions stable?
No. They are marked as being in Development, so names and attributes can change. Pin versions and test upgrades.
Which spans should an AI agent emit?
At minimum, a span for the agent invocation, spans for model calls, and spans for tool execution, all connected in one trace. Add spans for MCP calls and retrieval where they apply.
Should I capture prompts and completions?
Only where policy allows. Content is opt-in in the conventions because it can contain sensitive data. Mask or exclude it where required.
How do I avoid vendor lock-in for AI telemetry?
Instrument with OpenTelemetry, use standard attributes where they exist, keep custom attributes in your own documented namespace, and confirm which convention version your chosen backend expects.
Do I need custom attributes?
Usually yes, for things the standard does not yet cover, such as guardrail decisions, human approvals and business outcomes.