The OTel GenAI Spec Has an Implicit Reader

Every spec has an implicit reader. The OpenTelemetry GenAI semantic conventions are worth reading closely, less for what they define than for who they assume is looking at the data.

Take agent identity. The spec defines gen_ai.agent.id, gen_ai.agent.name, and as of v1.40, gen_ai.agent.version. These tell you which software artifact ran. A developer tracing a failed workflow back to a specific agent build gets exactly what they need. An auditor looking at the same run is trying to answer a different set of questions: who authorized this agent to act, under what constraints, and whether those constraints held. The spec identifies the software; the delegation that put the software in motion goes unaddressed.

Tool calls follow the same pattern. gen_ai.tool.call.arguments and gen_ai.tool.call.result capture what went into a tool and what came back. The spec even distinguishes tool types: function for client-side execution, extension for agent-side API calls, datastore for data access. That taxonomy is genuinely useful. It lets a developer reading a trace understand immediately whether a tool ran locally, called an external API, or queried a data store, which matters a lot when you're diagnosing where a workflow broke. There's no attribute, though, for whether the tool call was permitted by policy, approved by a person, or bounded within a stated permission scope. The spec records what happened. Permission and authorization live outside its current vocabulary.

Token usage is well-covered. Input tokens, output tokens, cache-read and cache-creation variants, a required duration metric. An operator can reconstruct what a workflow cost after the fact. What they can't do from the spec alone is set a per-task budget, detect when spending approaches a threshold, or find evidence that a cost limit was enforced. The attributes support cost observation, and cost governance requires infrastructure the spec doesn't describe.

Evaluation events tell a similar story. gen_ai.evaluation.score.value and gen_ai.evaluation.score.label let you record quality assessments: relevance, correctness, pass/fail. These are developer-grade quality signals. A compliance team looking for evidence that human oversight was effectively exercised, as the EU AI Act requires for high-risk systems, would find no corresponding event type. No attribute for a human approval decision. No binding between an approval and the specific action it authorized.

Content capture is off by default, gated behind OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT. The spec offers three modes: not recorded, captured on span attributes, or stored externally with a reference URL. A reasonable privacy-first design for debugging. Accountability, where reconstructibility is the whole point, needs something more.

None of this makes the conventions wrong. Every attribute in the GenAI namespace is still marked "Development" with no public stabilization timeline. And the conventions are genuinely useful for the problem they were designed around: helping developers understand what their GenAI applications are doing. The implicit reader is someone with access to traces, looking for bugs.

The gap appears when that reader changes. When it's an auditor tracing a delegation chain, an operator enforcing cost boundaries, a compliance team documenting that oversight actually happened. Production agent systems need traces that carry authorization records, approval evidence, and policy enforcement artifacts the spec doesn't yet reach. The distance between what the spec captures and what these readers need is where enterprise adoption friction quietly accumulates. Debugging and accountability draw on the same underlying data, and they need very different things from it.