.NET: [Bug]: Microsoft.Agents.AI.OpenTelemetryConsts is internal

[viul-sc]

Description

I would like to reuse OTel Semantic conventions defined in Microsoft.Agents.AI.OpenTelemetryConsts class.
Unfortunately not possible now because the class is marked as internal.
Is it possible to make it public?

Code Sample

Error Messages / Stack Traces

Package Versions

main branch

.NET Version

any

Additional Context

No response

[challaravinath]

The Ask is to MakeMicrosoft.Agents.AI.OpenTelemetryConstsconsumable from outside the assembly

Problem:
Microsoft.Agents.AI.OpenTelemetryConsts is marked internal, so consumers can't reference the OpenTelemetry conventions it defines. Two distinct things are locked away:

1. DefaultSourceName ("Experimental.Microsoft.Agents.AI")the ActivitySource name used by OpenTelemetryAgent and compaction tracing.
2. The GenAI.* attribute/span keys gen_ai.operation.name, gen_ai.agent.id, gen_ai.agent.name, invoke_agent, etc.

Why this is a concrete gap, not just a nice-to-have
the usage documented in ADR 0003 (https://github.com/microsoft/agent-framework/blob/main/docs/decisions/0003-agent-opentelemetry-instrumentation.md) tells users to wire up tracing like this:

  using var tracerProvider = Sdk.CreateTracerProviderBuilder()
      .AddSource(AgentOpenTelemetryConsts.DefaultSourceName)
      .AddConsoleExporter()
      .Build();

This doesn't compile against the shipped package:

• The class is internal, so DefaultSourceName isn't reachable.
• The type name in the doc (AgentOpenTelemetryConsts) no longer exists it was renamed to OpenTelemetryConsts in .NET: Update OpenTelemetry Agent - Added Demo, AIAgentMetadata and Agent.GetService()  #356.

As a result, the only way to subscribe to the framework's agent spans today is to hardcode the literal Experimental.Microsoft.Agents.AI", which is brittle and breaks silently if the source name ever changes.

Design constraint to consider
This telemetry layer was intentionally built to mirror Microsoft.Extensions.AI's OpenTelemetryChatClient ADR 0003
(https://github.com/microsoft/agent-framework/blob/main/docs/decisions/0003-agent-opentelemetry-instrumentation.md) lists "Microsoft.Extensions.AI Alignment" as one of its stated design goals and MEAI
keeps its equivalent type internal (internal static class OpenTelemetryConsts in src/Libraries/Microsoft.Extensions.AI/OpenTelemetryConsts.cs). So fully publicizing this class diverges from that precedent
and commits the team to the full gen_ai.* set as supported API surface worth a deliberate call rather than a blanket flip.

Proposed options

• Option A expose only what's needed to subscribe (recommended). Surface just the source name as public API either public const string OpenTelemetryConsts.DefaultSourceName, or a public ActivitySource /
  source-name member on OpenTelemetryAgent. Solves the actual .AddSource(...) gap with minimal surface and keeps the gen_ai.* keys internal. Fix the stale ADR example in the same change.

• Option B make the class public. Mark OpenTelemetryConsts (and members) public, gated with [Experimental(DiagnosticIds.Experiments.AgentsAIExperiments)] to match the project's convention for unstable API.
  Maximizes reuse but is the largest API commitment and breaks MEAI symmetry.

• Option C documentation only. Note that the gen_ai.* keys come straight from the OpenTelemetry GenAI semantic conventions (https://opentelemetry.io/docs/specs/semconv/gen-ai/) and can be referenced
  directly; still needs a supported way to obtain the source name, so this likely pairs with A.

Which direction do you prefer? Happy to send a PR leaning toward Option A plus the ADR doc fix unless you'd rather expose the whole class.

[moonbox3]

Could you please help us understand how having these constants as public would help your use-case? Thanks.

[viul-sc]

Hi Challa Ravi (@challaravinath), Evan Mattson (@moonbox3), thank you for looking into this.

Due to #3723, we cannot use OpenTelemetry provided by the MAF. We will need to use our own implementation. For that, we will need constants representing OTel semantic conventions. The official OTel open-telemetry/semantic-conventions-genai repo does not provide C# implementation of the conventions.

Defining own constants in our codebase will be a small effort. But we prefer to rely on constants supplied by OTel or Microsoft libraries if that is possible.