@trask If span kind INTERNAL does not have server.address and server.port, would it enforce to have an HTTP server span to capture these attributes?

Does not have token usage attributes (gen_ai.usage.input_tokens, gen_ai.usage.output_tokens, gen_ai.usage.cache_read.input_tokens, gen_ai.usage.cache_creation.input_tokens) — child inference spans provide token data directly

Would this require any inference client being used by agent to have tracing enabled assuming those client libs emit traces? For cases where I use openai client lib to call LLM but I do not have opentelemetry-instrumentation-openai-v2 installed

Would this require any inference client being used by agent to have tracing enabled assuming those client libs emit traces?

I believe so.

This feels more like an implementation limitation than a semantic conventions one. Not every agent invocation exposes token usage in its return value, especially in-process ones. So if the inference client itself isn’t instrumented/traced, instrumentation usually has no cheap way to accurately capture the agent’s token usage.

Would this require any inference client being used by agent to have tracing enabled assuming those client libs emit traces?

I believe so.

This feels more like an implementation limitation than a semantic conventions one. Not every agent invocation exposes token usage in its return value, especially in-process ones. So if the inference client itself isn’t instrumented/traced, instrumentation usually has no cheap way to accurately capture the agent’s token usage.

Providing information like token usage (not limited to it) should be responsibility of the agent framework rather than instrumentation lib in my opinion. For example, OpenAI Responses API does it no matter whether it is instrumented or no. Instrumentation libs should definitely capture it.

Providing information like token usage (not limited to it) should be responsibility of the agent framework rather than instrumentation lib in my opinion.

Agree with you. So in any case, we should do our best to count token usage in invoke_agent, unless the framework does not provide a way to do so, right?

@trask If span kind INTERNAL does not have server.address and server.port, would it enforce to have an HTTP server span to capture these attributes?

a few options:

• HTTP (or other protocol) server span
• "opt-in" to stamping server.* attributes on the span (it is generally acceptable for users to do this, I don't think generic frameworks would know the server.* values anyways)
• introduce invoke_agent SERVER span (your Invoke agent server span #3473)

Providing information like token usage (not limited to it) should be responsibility of the agent framework rather than instrumentation lib in my opinion.

Agree with you. So in any case, we should do our best to count token usage in invoke_agent, unless the framework does not provide a way to do so, right?

I brought back token usage on internal spans to make this PR easier to move forward (as it was intended to mostly be a mechanical change) and we can discuss that issues separately.