AI Agent Observability: The OpenTelemetry Standard in 2026

Key Takeaways

• The observability standard for AI agents is being written right now, and it is not stable yet. OpenTelemetry's GenAI semantic conventions define spans and metrics for agents, tools, and Model Context Protocol calls, and every one of them is marked "Development," not stable.
• There is now a shared vocabulary for agent behavior. The conventions define operations including create_agent, invoke_agent, plan, invoke_workflow, and execute_tool, so an agent's planning, delegation, and tool use can be traced with consistent names across frameworks.
• Tool calls get first-class spans. An execute_tool span carries gen_ai.tool.name, gen_ai.tool.call.id, and the tool type, making each tool invocation an inspectable unit rather than an opaque step.
• Model Context Protocol has its own conventions. OpenTelemetry defines mcp.client and mcp.server spans and four MCP metrics, and recommends following them "instead of RPC semantic conventions" because they carry domain-specific context.
• Logging agent inputs is a privacy decision. Message and tool-argument attributes are opt-in by default, and the spec warns each is "likely to contain sensitive information including user/PII data."
• The market is consolidating around this. In August 2026 Dynatrace signed a definitive agreement to acquire Arize, whose OpenInference tracing is "built on OpenTelemetry."
• An AI SRE that speaks MCP maps naturally onto these spans. The emerging conventions describe exactly the tool-call and cost surface an incident-investigation agent already produces.

AI agent observability is the practice of tracing an autonomous agent's reasoning, tool calls, and cost as structured telemetry, and as of 2026 OpenTelemetry has a dedicated set of GenAI semantic conventions that give those traces standard names, though the conventions are still marked Development rather than stable. For an SRE who already lives in traces and spans, this means agent behavior is becoming just another instrumented system, with a defined vocabulary for planning, delegation, and tool use. This post covers what the conventions actually define, where they stand, and why an MCP-native investigation tool fits them cleanly.

What are the OpenTelemetry GenAI semantic conventions for AI agents?

They are a standard set of span, metric, and attribute names for instrumenting generative-AI and agent systems. The conventions moved in 2026 out of the main semantic-conventions repository into a dedicated one, which self-describes as "Semantic Conventions for Generative AI (GenAI), including spans, metrics, and events for GenAI clients, MCP (Model Context Protocol)." The old documentation path now carries a notice that it "has moved and is no longer maintained in this repository," so the semantic-conventions-genai repository is the source to cite.

The practical payoff is a shared vocabulary. Before this, every framework named agent operations differently, and a trace from one agent stack meant nothing to tooling built for another. The conventions define a common gen_ai.operation.name enum that includes chat, create_agent, invoke_agent, invoke_workflow, plan, execute_tool, embeddings, and retrieval, among others. An SRE reading a trace can now tell a planning step from a tool call from a sub-agent invocation without knowing which framework produced it.

Are the OpenTelemetry GenAI conventions stable or experimental in 2026?

They are experimental. Every relevant document in the repository, the agent spans, the client spans, and the MCP conventions, carries the status line "Status: Development." In OpenTelemetry's maturity model, Development is below Stable, which means attribute names and semantics can still change and no stability guarantee applies yet.

This is the honest framing for anyone adopting them: the vocabulary is usable today and worth adopting, but it is a moving target, not a frozen contract. OpenTelemetry's own May 2026 writeup on GenAI observability puts it as conventions that are "already in use today and under active development." Instrument against them, but expect churn, and pin the version you build on.

Convention area	Defines	Status (2026)
Agent and framework spans	create_agent, invoke_agent, plan, invoke_workflow	Development
GenAI client spans	chat, execute_tool, model request/response attributes	Development
MCP conventions	mcp.client / mcp.server spans, four MCP metrics	Development
Stable release	none published	not stable

What span and attribute names does OpenTelemetry define for agents and tools?

The conventions split agent activity into a handful of span types with defined operation names and span kinds.

• Create agent. The gen_ai.operation.name is create_agent, the span name "SHOULD be create_agent {gen_ai.agent.name}," and the span kind is CLIENT. It captures the construction of an agent.
• Invoke agent. The operation is invoke_agent, split into a CLIENT span for hosted agents (the examples name the OpenAI Assistants API and AWS Bedrock Agents) and an INTERNAL span for in-process agents (the examples name LangChain and CrewAI).
• Plan. The operation is plan, described as an "agent planning or task decomposition phase," the step where an agent "formulates a strategy before executing it." Making planning its own span is what lets you see an agent's intent separately from its actions.
• Invoke workflow. The operation is invoke_workflow, for a "coordinated process composed of multiple agents," which is how multi-agent coordination shows up in a trace.
• Execute tool. The operation is execute_tool, the span name "SHOULD be execute_tool {gen_ai.tool.name}," and the span kind is INTERNAL.

Agents and tools carry identifying attributes. An agent span uses gen_ai.agent.id, gen_ai.agent.name, and gen_ai.agent.description, and conversations are tied together by gen_ai.conversation.id, "the unique identifier for a conversation (session, thread)." A tool span uses gen_ai.tool.name (required), gen_ai.tool.call.id, gen_ai.tool.description, and gen_ai.tool.type with values such as function, extension, and datastore. That is enough structure to answer "which tool did this agent call, with what call id, inside which conversation," which is the first question any incident review of an agent asks.

How does OpenTelemetry trace Model Context Protocol tool calls?

With dedicated MCP conventions, distinct from generic RPC instrumentation. The MCP document defines two span types, mcp.client and mcp.server, and recommends that when "instrumenting MCP calls, it's RECOMMENDED to follow MCP conventions instead of RPC semantic conventions" because the MCP spans "provide domain-specific context."

Four metrics are defined: mcp.client.operation.duration, mcp.server.operation.duration, mcp.client.session.duration, and mcp.server.session.duration. Spans carry mcp.method.name (required, with values such as tools/call, tools/list, and initialize), mcp.session.id, and mcp.protocol.version. The conventions also handle trace context propagation into MCP requests and note MCP's transport independence, expecting clients to implement "at least stdio or Streamable HTTP."

There is a deliberate bridge to the tool spans above. The MCP document states that "MCP tool call execution spans are compatible with GenAI execute_tool spans," and that if outer GenAI instrumentation is already tracing the tool execution, the MCP layer "SHOULD NOT create a separate span" but instead add MCP-specific attributes to the existing one. That avoids double-counting a single tool call as two spans.

What are the risks of logging agent prompts and tool arguments?

The main risk is that the most useful attributes to capture are also the most sensitive, so they are opt-in by default. The conventions mark message and content attributes, including gen_ai.input.messages, gen_ai.output.messages, and gen_ai.tool.call.arguments, as opt-in, and warn on the message attributes that each "is likely to contain sensitive information including user/PII data."

For an SRE this is a governance decision, not a default to accept blindly. Capturing full prompts and tool arguments makes a trace far more useful for debugging an agent, and far more dangerous if that trace lands in a log store with broad access. The safe posture is to treat agent content attributes the way you already treat request bodies that may contain secrets: capture deliberately, redact where possible, and control who can read the resulting spans. The same care applies to tool outputs, since a tool result folded into a span can carry data the agent was never meant to persist.

How does an MCP-native AI SRE map onto these conventions?

An investigation agent that already exposes its tools over MCP is producing exactly the activity these spans describe: agent invocations, planning steps, and a stream of tool calls, many of them MCP method calls with sessions and durations. The conventions give that activity standard names, which makes an agent's work legible to the same observability stack an SRE uses for everything else.

Aurora is MCP-native. It exposes its tools over MCP with streamable HTTP transport, in tiers where powerful tools sit behind an allowlist, and it is used from clients including Cursor, Claude Desktop, Claude Code, Codex, Windsurf, and Cline. That maps directly onto the MCP conventions: mcp.client and mcp.server spans, mcp.method.name values like tools/call, and session durations. Aurora also tracks cost per investigation and builds a per-incident execution timeline, which is the same instinct these conventions formalize, making an agent's actions and their cost inspectable after the fact. The point is not that Aurora emits gen_ai.* spans today, but that an MCP-native, cost-aware investigation tool is already structured the way the standard is heading. How that investigation works end to end is covered in AI-powered incident investigation, and how it fits the incident lifecycle in the SRE incident lifecycle with AI agents.

The market is moving the same way. Dynatrace's August 2026 agreement to acquire Arize folds in OpenInference, described as "an open specification for AI tracing built on OpenTelemetry," a sign that agent observability is consolidating onto the OpenTelemetry base rather than fragmenting into per-vendor formats.

The summary

OpenTelemetry now defines a real vocabulary for AI agent observability: spans for creating, invoking, and planning agents, an execute_tool span for tool calls, and dedicated mcp.client and mcp.server conventions with four metrics for Model Context Protocol. The whole set is marked Development, so it is usable but not yet stable. The most valuable attributes, prompts and tool arguments, are opt-in because they carry PII. For SREs, the takeaway is that agent behavior is becoming instrumentable like any other system, and an MCP-native, cost-aware investigation agent is already shaped for where the standard is going.

Sourcing note. Span names, operation names, attribute names, MCP spans and metrics, and every "Status: Development" label are quoted from the OpenTelemetry semantic-conventions-genai repository on GitHub, verified 31 August 2026. The Dynatrace agreement to acquire Arize and the OpenInference description are quoted from Dynatrace's blog post dated 13 August 2026. The conventions are not stable; no stable release exists as of this writing. Aurora's MCP transport, client list, and cost-tracking are described from its open-source repository and documentation.