Why agent telemetry has converged faster than agent identity

The argument over how agents should identify themselves is in its second year and has produced four competing patterns: MCP server cards, A2A Signed Agent Cards, ERC-8004's three on-chain registries, and AP2 verifiable-credential mandates. The argument over how agents should report what they did is over. While the identity discussion is still pulling in different directions, OpenTelemetry's GenAI Semantic Conventions have become the shared schema for agent telemetry. Datadog adopted them natively on December 1, 2025. New Relic, Dynatrace, Honeycomb, and Grafana followed. The OpenLLMetry extension built on top of the spec ships with integrations to twenty-four observability platforms and fifteen LLM providers. The formal status of the convention is still "Development." Production deployments have moved on without waiting for it.

That asymmetry is the interesting story. Telemetry is the only horizontal layer in the agent stack where the major players are already speaking the same vocabulary in production. Identity, payments, and registries have each spent the last year producing competing standards. The telemetry layer skipped that step.

What the schema actually standardizes

The GenAI Semantic Conventions formalize three distinct span types:

The attribute schema below those spans is more specific. The current release maps include gen_ai.request.model, gen_ai.usage.input_tokens, gen_ai.usage.output_tokens, gen_ai.usage.total_tokens, gen_ai.provider.name, gen_ai.response.finish_reasons, gen_ai.client.operation.duration, and gen_ai.client.token.usage. These are the fields Datadog's native adapter converts to its internal schema; the same fields are exported into New Relic, Honeycomb, Grafana, and the rest of the OpenLLMetry integration list without code changes from the application.

A row in this telemetry vocabulary tells a downstream consumer: which model was called, how many tokens it used, how long the call took, whether the call was a tool invocation or an agent run, and which vendor served it. That set of fields is not exotic. It is the working schema the agent ecosystem has converged on while the specification carries a "Development" label and the SIG continues to refine it.

Why this layer converged where others haven't

The agent web has been trying to standardize four different things at the same time. Three of them are vertical concerns that depend on what is being described:

• Identity has to commit to a trust model. ERC-8004's on-chain approach is structurally different from MCP's hosted registry, which is different from A2A's signed card. The fragmentation is downstream of a real philosophical disagreement about where root trust lives.
• Payments have to commit to a settlement substrate. x402 settles on Base or Solana; ACP routes through Stripe; TAP routes through Visa. The four protocols described in our payment-stack post cannot collapse into one because the underlying rails are different.
• Registries have to commit to a governance model. AAIF is a Linux Foundation directed fund; ERC-8004 is on-chain; the Agenstry registry is operated by us. Each governance choice carries different trust and update properties.

Telemetry is the one layer that does not have to commit to any of those choices. An agent_run span is the same shape whether the agent is talking to Claude, GPT-5, Gemini, or a self-hosted model. The gen_ai.usage.input_tokens attribute means the same thing whether the agent is paying for those tokens through x402 or AP2 or invoice. Observability is a horizontal concern that sits beneath every vertical choice. There is no political contention.

The economic incentive points the same direction. Every observability vendor wants to sell into AI workloads. Every AI workload needs telemetry that the customer can ship to multiple vendors. The path of least resistance for both sides is a shared OpenTelemetry-based schema. Vendor-specific instrumentation is dead the moment a second vendor supports the open one.

What this means for the registry layer

A registry that publishes probe results is, in practice, publishing aggregations of telemetry. If the underlying telemetry uses the GenAI Semantic Conventions, the aggregation is portable across consumers. "Latency at p95 was 1.4 seconds, average token usage was 4,200 input and 1,100 output, finish reason tool_calls in 38% of runs" is a sentence that compiles for any consumer reading the same schema.

That portability is the load-bearing piece. The funnel pattern Agenstry publishes (discovered, responded, returned a valid card) is a coarse measurement today. The finer breakdown that would make probe results more useful to a downstream consumer (latency distribution, error rate, finish-reason composition, tool-call success ratios) becomes producible at population scale only because the underlying telemetry has converged.

The same observation applies in reverse to MCP server operators. Uber's MCP gateway described agents emitting standard telemetry that the gateway can inspect. The work of getting from "we ran 60,000 agent executions this week" to "27% of them were tool_call spans and 14% of those returned errors" is the work the SemConv schema makes routine. Without it, every gateway has to invent its own field names and every consumer of those events has to re-learn them per vendor.

What we're watching

Three things, observable within the next two academic-and-release cycles:

1. Whether the GenAI Semantic Conventions get promoted from "Development" to "Stable." The transition plan note says the plan will be updated before that promotion happens. Once it does, instrumented code paths that today produce experimental attributes become contractually stable. Vendors will have to honor the schema without breaking changes.
2. Whether agent_run spans get a registry-linked identity attribute. The current schema captures gen_ai.provider.name for the model vendor. It does not yet capture a registry-resolvable identifier for the agent itself — there is no gen_ai.agent.identity attribute that ties an agent_run span back to an MCP server card, an ERC-8004 token ID, or an A2A signed card hash. The first attribute that does this will be the practical link between the telemetry layer and the identity layer.
3. Whether the agent-evaluation literature starts citing OTel attributes as the basis for reproducibility claims. The reliability papers from earlier this year built run-to-run variance metrics on top of ad-hoc instrumentation. If a 2026 H2 reliability paper expresses its variance metrics in terms of gen_ai.client.operation.duration and gen_ai.response.finish_reasons distributions, the benchmark-to-production gap closes by one full step.

The headline argument in the agent web has been about who gets to authenticate which agent to whom. The quieter convergence has been about what every agent reports while it does the work. The first question is unresolved. The second is closer to settled than the noise suggests, which makes it the most usable substrate for everything else that has to be measured on top of it.

Sources

• Inside the LLM Call: GenAI Observability with OpenTelemetry — OpenTelemetry Blog, 2026.
• Semantic Conventions for Generative AI Systems — OpenTelemetry, accessed May 2026.
• Datadog LLM Observability natively supports OpenTelemetry GenAI Semantic Conventions — Datadog Engineering Blog, December 1, 2025.
• traceloop/openllmetry on GitHub — OpenLLMetry source repository, v0.60.0 (April 19, 2026), accessed May 2026.
• OpenTelemetry for AI Agents: Observability, Tracing, and the GenAI Semantic Conventions — Zylos Research, February 28, 2026.