Add gen_ai.harness.name attribute to identify the orchestrating AI system

[josephwangrb]

Motivation

The current GenAI semantic conventions provide attributes for the provider (gen_ai.provider.name, e.g., "anthropic"), the model (gen_ai.request.model, e.g., "claude-3-opus"), and optionally a user-defined agent (gen_ai.agent.name, e.g., "Math Tutor").

However, there is no attribute for the orchestrating AI system or harness itself — the product-level system that coordinates reasoning, tool calling, and workflow execution on top of a provider's models.

For example:

• Claude is an orchestration harness built by Anthropic. It reasons, plans, calls tools, and chains operations — but the provider is "anthropic" and the model is "claude-3-opus".
• ChatGPT is an orchestration harness built by OpenAI, distinct from the provider "openai" and model "gpt-4".
• Cursor and Copilot are orchestration harnesses that may use models from multiple providers.

Today, there is no standard way to record which orchestrating system produced a trace.

Proposed Attribute

Field	Value
Name	gen_ai.harness.name
Type	string
Description	The name of the AI orchestration system or harness that coordinates GenAI operations, including reasoning, tool calling, and workflow execution.
Examples	"Claude", "ChatGPT", "Gemini", "Copilot", "Cursor"
Requirement Level	Recommended (when available)

Why This Is Distinct from Existing Attributes

Attribute	What it identifies	Example
gen_ai.provider.name	The API provider / company	"anthropic"
gen_ai.request.model	The specific model weights	"claude-3-opus"
gen_ai.agent.name	A user-defined agent built on top	"Math Tutor"
gen_ai.harness.name (proposed)	The orchestrating AI system/product	"Claude"

Key distinctions:

• The same provider (e.g., anthropic) may power multiple harnesses (Claude, Cursor, a custom app).
• The same model may be used by different harnesses.
• The same harness may use models from different providers (e.g., Cursor can use Claude or GPT-4).
• An agent is a user-defined construct within a harness, while the harness is the platform itself.

Use Cases

1. Observability: Operators need to know which orchestrating system produced a trace to debug issues, attribute costs, and understand behavior — not just which provider or model was involved.
2. Multi-harness environments: Organizations may use multiple AI systems (Claude, ChatGPT, Copilot) and need to distinguish their telemetry.
3. Cost attribution: Different harnesses may have different pricing, even when using the same underlying model.
4. Drift detection: Comparing behavior across different orchestrating systems using the same model requires identifying the harness.

Open Questions

• Should this be gen_ai.harness.name or a different naming convention (e.g., gen_ai.orchestrator.name, gen_ai.system.name)?
• Should there be well-known values (similar to gen_ai.provider.name), or should it be free-form?
• Should a gen_ai.harness.version companion attribute also be defined?

[Cirilla-zmh]

What problem is this attribute intended to solve? If it’s only meant to identify the component/framework that a span comes from, why can’t instrumentation-scope solve this problem?

[josephwangrb]

@Cirilla-zmh Thanks for the thoughtful question — this is a really helpful point to clarify.

My understanding is that instrumentation scope answers who emitted the telemetry, while this attribute is trying to capture which GenAI system/runtime this span belongs to.

So to clarify, the intent here is not to identify the component or framework that emitted the span (which I agree is already covered by instrumentation scope in OpenTelemetry, e.g io.opentelemetry.openai-instrumentation). Rather, the goal is to identify the GenAI system/runtime being observed (e.g., Cursor, ChatGPT, Claude Code), which feels like a slightly different dimension.

In practice, I’ve seen cases where:

• the same instrumentation (e.g., a gateway or SDK) emits spans for multiple systems → same scope, different systems
• the same system is observed via different instrumentation → different scope, same system

So it seemed like instrumentation scope alone might not fully capture this distinction, but I could be missing something here and would love your thoughts.