We got our first PR merged into a significant repository: OpenTelemetry's semantic conventions for generative AI. Liudmila Molkova merged #556 on 30 October. It sets out how GenAI instrumentation can pass a conversation ID to the calls nested inside an agent. As instrumentations adopt it, you can find a conversation's spans by that ID instead of walking the trace.
ILLUSTRATIVE TRACE / ONE CONVERSATION, ONE PROCESS
Which spans can you find by conversation?
A support agent hands work to a sub-agent, a tool and a remote agent. Pick a view, then read the query.
gen_ai.conversation.id = "conv_5j66"5 of 6 spansinvoke_agentSupportAgent · Agent frameworkconv_5j66framework sessionchatgpt-4Inference · Model clientconv_5j66from context1execute_toollookup_orderTool · Agent frameworkconv_5j66framework sessioninvoke_agentBillingAgent · Agent frameworkconv_5j66framework sessionchatgpt-4Inference · Model clientconv_5j66from context1invoke_agentRefundsRemote agent · Hosted agent clientsess_8tq2its own session2
gen_ai.client.Metric · model client- 1Pass it to nested calls in the same process
- 2Prefer the library’s own value
- 3Share only what’s listed
- 4Only on signals that reference it
Five of six spans carry it, without walking the trace.The framework puts the conversation ID in context, and the model client in the same process records it on both chat spans. The remote agent’s client has its own session ID, and the library’s value wins. The token metric stays without it, because GenAI metrics don’t reference the attribute.
Explanation and primary sources
An illustrative trace of one support conversation in one process. Without propagation, only spans whose own library knows the conversation record its ID, so a query by conversation finds three of six spans. With the rule, the agent framework passes the ID in context and the nested model calls record it too. A remote agent's library has its own session ID, and that value wins. The token metric never carries the ID because GenAI metrics don't reference it. The third view shows why agent names stayed out of the list: inherited, the remote agent's span would name its caller.
- Merged pull request #556
- Attributes shared across operations
- gen_ai.conversation.id definition
- The wrong-agent case in review
Who follows these conventions
OpenTelemetry is the open standard for traces, metrics and logs. It graduated in the CNCF in May, and the CNCF ranks its project velocity second only to Kubernetes. Its semantic conventions are the shared names: when every library records the model in gen_ai.request.model, any backend can read telemetry from any of them without a custom mapping.
The GenAI conventions describe model calls, agents, tools, evaluations and MCP. They moved into their own repository in May, and by 30 October more than 110 people had contributed and 269 pull requests had merged there. Its reference scenarios check the conventions against 30 Python libraries, from the OpenAI and Anthropic clients to LangChain, CrewAI, Google ADK and Pydantic AI.
On the reading side, Datadog, Honeycomb, Grafana Cloud, Dynatrace, Opik, W&B Weave and Pydantic Logfire document grouping an agent conversation by gen_ai.conversation.id. Grafana's guide warns that without it, each trace becomes its own conversation.
FROM THE REPOSITORY’S REFERENCE REPORTS / 30 OCTOBER 2026
One document between writers and readers
The reference scenarios check 30 libraries against the GenAI conventions, and backends read the same names. Gold marks a library that records the conversation ID and a backend that groups conversations by it. Pick a span to see which libraries emit it.
Where the conversation ID is recorded today 11 of 43
In their scenarios, 6 of 30 libraries record the conversation ID.Count every place a library emits a span that references the attribute and you get 43; the ID is in 11 of them. The rule in #556 is how a conversation that the framework knows can reach the spans nested inside it.
Write telemetry 30 libraries · scenario names
Agent frameworks 12
langchainllamaindexcrewaiautogenopenai-agentspydantic-aigoogle-adkadk_a2aagent-frameworkclaude-agent-sdkhaystackdspy
Model clients 11
openaianthropicgoogle-genaivertexaiazure-openaiazure-ai-inferenceaws-bedrockcoheremistralaigroqlitellm
Hosted agents and protocols 5
openai-assistantsaws-bedrock-agentaws-bedrock-agentcoreazure-ai-foundrya2a-python
Evaluation 2
deepevalazure-ai-evaluation
OpenTelemetry semantic conventions for generative AI Development status
- Inference
- Embeddings
- Agents
- Tools
- Metrics
- Events
- MCP
- A2A
gen_ai.conversation.idRead telemetry 14 backends document the conventions
- Datadog
- Honeycomb
- Grafana Cloud
- Dynatrace
- Opik
- W&B Weave
- Pydantic Logfire
- Langfuse
- Arize Phoenix
- MLflow
- LangSmith
- Braintrust
- New Relic
- Google Cloud
Gold: 7 group an agent conversation by gen_ai.conversation.id, so the spans that carry it join the conversation.
Explanation and primary sources
The GenAI semantic conventions sit between the libraries that write telemetry and the backends that read it. The repository's reference scenarios check 30 Python libraries: 11 model clients, 12 agent frameworks, five hosted agents or agent protocols and two evaluation libraries (grouping ours). In those scenarios, six libraries record gen_ai.conversation.id on at least one span: adk_a2a, agent-framework, google-adk, openai-assistants, aws-bedrock-agent and a2a-python. By span: agent invocation inside the process 2 of 8 libraries, remote agent invocation 2 of 4, workflow 1 of 4, inference 2 of 14, tool execution 2 of 11, A2A client and server 1 of 1 each: 11 of 43 in all. Scenario coverage shows what each reference scenario exercises, not everything a library can do. On the reading side, 14 backends document reading the GenAI conventions. Datadog, Honeycomb, Grafana Cloud, Dynatrace, Opik, W&B Weave and Pydantic Logfire document grouping an agent conversation by gen_ai.conversation.id; Langfuse, Arize Phoenix, MLflow, LangSmith, Braintrust, New Relic and Google Cloud document reading the conventions. Backend documentation read 30 October 2026; no endorsement or partnership is implied.
- Reference implementations and reports
- Inference span report
- Grafana Cloud: OpenTelemetry for agents
- Honeycomb: agents
- Datadog: OpenTelemetry instrumentation
- Dynatrace: AI observability attributes
- CNCF: OpenTelemetry graduation
The conversation stopped at the agent
An agent framework usually knows which conversation it's serving, such as a LangChain or ADK session. The model client it calls usually doesn't. Its instrumentation sees one request and one response.
The reference reports show the gap. In their scenarios, 14 of the 30 libraries emit inference spans and two of them record a conversation ID there. Count every place a library emits a span that references the attribute and you get 43. The ID is in 11 of them.
OpenTelemetry usually avoids repeating an attribute on every layer. Liudmila opened issue #522 after a GenAI SIG call found that this makes GenAI queries hard: the conversation is useful on the agent span, its tool calls and its model calls.
The rule
The merged section in the GenAI overview sets four rules. Instrumentations may pass the listed attributes to nested instrumentations in the same process. When the instrumented library has its own value, that value should win over the outer context. They shouldn't pass on anything unlisted, or record these attributes on a signal that doesn't reference them. The list holds one attribute: gen_ai.conversation.id.
OpenTelemetry's Python GenAI utility has passed the ID this way since September: an operation without its own conversation ID takes the one from the enclosing context. The merged section makes that the convention for every instrumentation, in any language.
The last rule keeps the ID off metrics. GenAI metrics don't reference it, and a label per conversation would start a new series for every conversation.
Review made it better
Our first version was an 18-line summary of where two attributes already appeared: gen_ai.agent.name and gen_ai.conversation.id. Liudmila asked us to make it "normative and more specific", proposed the wording we applied and asked for links to the canonical definitions: a repeated definition goes stale and carries no normative weight.
Trask Stalnaker then found the case that changed the scope. If a nested call inherits the agent name, a request from a Planner agent to a remote agent can be recorded under Planner's name: the wrong agent. The GenAI SIG discussed it on its call and continued agent naming in #385, a draft that proposes gen_ai.main_agent.name. We removed the agent name.
The repository asks for two approvals from reviewers at different companies for non-editorial changes like this one. Liudmila and Trask both approved, and the change merged with one attribute and four rules.
FROM THE PUBLIC PULL REQUEST / 1–30 OCTOBER 2026
From two attributes to one
What the change carried at each step of its review.
- Opened
An 18-line summary of where two attributes already appear.
gen_ai.agent.namegen_ai.conversation.id- Summary
- Make it normativeLiudmila Molkova
Proposed rules for propagation, and links to the canonical definitions instead of repeating them.
gen_ai.agent.namegen_ai.conversation.id- Summary
- Revised and approvedLiudmila Molkova
A change like this also needs an approval from a reviewer at a second company.
gen_ai.agent.namegen_ai.conversation.id- Rules
- The wrong agentTrask Stalnaker
An inherited agent name can label a remote agent with its caller’s name. The SIG continues agent naming in #385.
gen_ai.agent.namegen_ai.conversation.id- Rules
- Agent name removed
The list keeps the conversation ID only.
gen_ai.agent.namegen_ai.conversation.id- Rules
- Approved and mergedTrask Stalnaker · Liudmila Molkova
Two wording suggestions applied, approvals from both reviewers, merged at 22:56 UTC.
gen_ai.agent.namegen_ai.conversation.id- Four rules
- days in review
- 30
- lines added
- 16
- approvals, two companies
- 2
- checks passed on the final commit
- 44
Explanation and primary sources
Opened on 1 October as an 18-line summary of where gen_ai.agent.name and gen_ai.conversation.id appear. On 12 October Liudmila Molkova asked for normative guidance, proposed its wording and asked for links to canonical definitions; the revision was approved the next day. The repository requires a second approval from another company for non-editorial changes. On 23 October Trask Stalnaker showed how an inherited agent name can identify the wrong agent; the GenAI SIG continued agent naming in #385, and the agent name was removed on 27 October. Trask approved on 30 October with two wording suggestions, both applied, and Liudmila approved and merged the change at 22:56 UTC.
- Pull request #556 and its review
- Issue #522
- Draft #385: main agent name
- Repository review policy
What to do in your instrumentation
If you maintain an agent framework's instrumentation, put the conversation ID in context when an agent or workflow starts, so nested GenAI instrumentation in the same process can record it. If you maintain a model client's, use the client's own conversation or thread ID when it has one and the context's otherwise. With no conversation ID, leave it unset: the attribute's definition rules out a new UUID, a trace ID or a hash of the request as a fallback. Keep the agent name per operation, and follow #385 for the main agent.
If you read the telemetry, a filter on gen_ai.conversation.id can return a conversation's inference and tool spans as instrumentations adopt the rule. The rule is optional, the conventions are in Development status and the change has merged on main without a tagged release, so check what your libraries record before you build a dashboard on it.
Why we contribute
We contribute to the key pillars of open-source AI to build trust. Besides visibility, the knowledge gained goes into what we build and offer.
This review taught us to keep the conversation and the agent apart. We can use that split when our agents hand work over: the conversation keeps its ID, each step names the agent that did it, and a missing ID stays missing. We don't run OpenTelemetry instrumentation ourselves yet.
Thanks to Liudmila Molkova for opening the issue, proposing the rule's wording and merging it, to Trask Stalnaker for the review that narrowed it, and to the GenAI SIG for the decision on agent naming. We prepared the change with AI assistance and said so in the PR.