Describe the Bug
EDIT on 15 June: I am using auto_instrument() from sap-cloud-sdk, so the span is auto generated by the tracer instead of using the custom invoke_agent_span() function mentioned in this user guide.
Based on this All-in on AI decision, the calling system (that calls an agent) must generate a conversation identifier and set it in the W3C baggage header on every request within a conversation. However, when I use sap-cloud-sdk to instrument a LangGraph agent, there is a different value of gen_ai.conversation.id in the invoke_agent LangGraph span set by traceloop, which derives the conversation ID from the context id of the A2A server of a LangGraph agent. When gen_ai.conversation.id is set in the W3C baggage header, all spans have the same gen_ai.conversation.id value EXCEPT the invoke_agent LangGraph span, which is an inconsistency.
Steps to Reproduce
- Run a LangGraph agent in https://github.tools.sap/Montana-AI-Singapore/a2a-server-samples/tree/main/appfnd-langgraph-basic and use
auto_instrument() from sap-cloud-sdk
- Copy
.env.example and fill up the variables accordingly. I used a local MLflow server and sent the traces via http/protobuf
- Run the agent
uv run app and send a message to the agent and inject gen_ai.conversation.id in the W3C baggage header
This is how the trace spans look:
Root span: gen_ai.conversation.id == 48e35936-82ab-4f1a-beaf-b2fa4273ac5e, generated by the calling system

invoke_agent LangGraph span: gen_ai.conversation.id == b01915bf-48a2-4f8b-9681-19bc166553c5

Expected Behavior
I expect to see consistent values of gen_ai.conversation.id in all the spans in my trace, following the decision on All-in on AI. This could mean:
- blocking traceloop from setting
gen_ai.conversation.id from traceloop.association.properties.thread_id, or
- overriding the value in invoke_agent LangGraph span such that the value is consistent.
Screenshots
No response
Used Versions
- Python version via
python --version: 3.12.12
- SAP Cloud SDK for Python version: 0.19.3, but tested on 0.25.1 in a colleague's env
- Framework version (if applicable, e.g., Flask, FastAPI): ...
Installed packages via pip list or uv pip list
Code Examples
Stack Trace
No response
Log File
Log file
...
Affected Development Phase
Development
Impact
Impaired
Timeline
No response
Describe the Bug
EDIT on 15 June: I am using
auto_instrument()fromsap-cloud-sdk, so the span is auto generated by the tracer instead of using the custominvoke_agent_span()function mentioned in this user guide.Based on this All-in on AI decision, the calling system (that calls an agent) must generate a conversation identifier and set it in the W3C baggage header on every request within a conversation. However, when I use
sap-cloud-sdkto instrument a LangGraph agent, there is a different value ofgen_ai.conversation.idin the invoke_agent LangGraph span set bytraceloop, which derives the conversation ID from the context id of the A2A server of a LangGraph agent. Whengen_ai.conversation.idis set in the W3C baggage header, all spans have the samegen_ai.conversation.idvalue EXCEPT the invoke_agent LangGraph span, which is an inconsistency.Steps to Reproduce
auto_instrument()fromsap-cloud-sdk.env.exampleand fill up the variables accordingly. I used a local MLflow server and sent the traces via http/protobufuv run appand send a message to the agent and injectgen_ai.conversation.idin the W3C baggage headerThis is how the trace spans look:

Root span:
gen_ai.conversation.id == 48e35936-82ab-4f1a-beaf-b2fa4273ac5e, generated by the calling systeminvoke_agent LangGraph span:

gen_ai.conversation.id == b01915bf-48a2-4f8b-9681-19bc166553c5Expected Behavior
I expect to see consistent values of
gen_ai.conversation.idin all the spans in my trace, following the decision on All-in on AI. This could mean:gen_ai.conversation.idfromtraceloop.association.properties.thread_id, orScreenshots
No response
Used Versions
python --version: 3.12.12Installed packages via
pip listoruv pip listCode Examples
# Your code hereStack Trace
No response
Log File
Log file
...Affected Development Phase
Development
Impact
Impaired
Timeline
No response