Telemetry Standards for the Agent Stack: Why OpenTelemetry Is Quietly Becoming the Agent Industry's Spine

Table of Contents

• Why Telemetry for Agents Is a Different Animal
• The Standard Everyone Is Quietly Adopting: OpenTelemetry GenAI
• What a Good Agent Trace Actually Contains
• The Signals Classic APM Never Anticipated
• Where the Standard Is Still Broken
• The Vendor Lock-In Trap Hiding in Your Tracing Library
• Telemetry as the Billing Substrate for GaaS
• A Practical Instrumentation Playbook
• Insights Most People Overlook
• References

Why Telemetry for Agents Is a Different Animal

For two decades, observability meant a fairly stable set of questions. Is the service up? How slow is the p99? Which downstream call is throwing 500s? Distributed tracing answered those by stitching together spans across microservices, and tools like Datadog and Honeycomb built empires on it.

Agents break the assumptions underneath that model in a specific way. A traditional request is deterministic in shape: the same endpoint produces roughly the same call graph every time. An agent's execution graph is generated at runtime by a model deciding, step by step, what to do next. The same prompt can produce three tool calls on Monday and eleven on Tuesday, loop twice, abandon a plan halfway, and finish with a different answer, all without anything "failing" in the way a 500 error fails.

So the question changes from "is it up and fast?" to "is it doing the right thing, for a defensible cost, and can I prove it after the fact?" That last clause matters more than people expect. When an agent is sold as a service, priced per task or per outcome, the model the whole GaaS infrastructure cost stack rests on, the telemetry isn't just for debugging. It's the evidence trail behind the invoice. You cannot run a per-outcome business on vibes.

This is why telemetry has gone from a nice-to-have at the bottom of the observability stack for agent infrastructure to something closer to load-bearing. And once it's load-bearing, the format you record it in stops being an implementation detail and becomes a strategic decision.

The Standard Everyone Is Quietly Adopting: OpenTelemetry GenAI

If you ask "is there a telemetry standard for agents?" the honest answer in 2026 is: there's one front-runner, and it's winning by default rather than by decree.

OpenTelemetry, the CNCF project that already standardized traces, metrics, and logs across most of the cloud-native world, has a dedicated working group defining GenAI semantic conventions. Semantic conventions are the boring, essential part: they specify the agreed-upon names and shapes for attributes, so that gen_ai.usage.input_tokens means the same thing whether it came from an OpenAI call, an Anthropic call, or a self-hosted Llama. You can read the current state in the OpenTelemetry GenAI semantic conventions, which now cover model calls, token usage, tool execution, and, increasingly, agent-level spans.

The reason this matters is leverage. The big agent frameworks and observability vendors have, mostly, stopped fighting over the wire format. LangChain's LangSmith, Arize Phoenix, Langfuse, Traceloop's OpenLLMetry, and the APM incumbents all either emit or ingest OTel-shaped GenAI data. When the people who'd normally compete on proprietary lock-in instead converge on a shared schema, that's the market telling you where the gravity is.

It's worth being precise about what "standard" means here, though. OpenTelemetry standardizes the envelope, how a span is structured, what an attribute is called, how it's exported. It does not yet fully standardize the semantics of agent behavior, what counts as a "reasoning step," how to represent a multi-agent handoff, how to attribute an outcome to a chain of decisions. The envelope is stable. The contents are still being argued over in GitHub issues. That gap is the whole story of where this space is going.

What a Good Agent Trace Actually Contains

Forget the spec for a second and picture what you'd want to see when an agent does something wrong. A complete agent trace should let you reconstruct the entire episode without re-running it.

In practice, a well-instrumented agent trace nests roughly like this:

• A root span for the whole task or session, carrying the user's goal, the agent identity and version, and the total cost and latency.
• Reasoning/planning spans capturing each model invocation: the rendered prompt (or a reference to it), the model and parameters, the raw completion, and token counts split into input, output, and, critically, cached tokens.
• Tool-call spans for every action the agent took: which tool, the arguments, the result or error, latency, and whether a retry fired. This connects directly to tool-calling reliability at the infrastructure layer, because most agent failures are tool failures wearing a trench coat.
• Retrieval spans when the agent hits memory or a knowledge store, recording the query, the documents returned, and their relevance scores.
• Decision/branch spans marking where the agent chose between options, looped, or gave up.

The discipline that separates useful telemetry from noise is causality. A flat list of "the agent called the search API, then called the calculator, then answered" is nearly worthless. What you need is the parent-child structure that shows the calculator call happened because the search returned a number the model decided to verify. Span context propagation, OTel's core trick, is what gives you that tree instead of a pile.

The Signals Classic APM Never Anticipated

This is where agent telemetry stops looking like a coat of paint on APM and starts looking like its own discipline.

Token and cost accounting per span. Latency you've always tracked. But tokens are simultaneously a performance metric, a cost metric, and a quality signal, a sudden jump in input tokens often means context bloat from the context-window economy, not a bug, yet it shows up on your bill all the same. Cost has to be a first-class span attribute, computed from token counts and the model's price, not a monthly reconciliation surprise.

Prompt and completion content. No APM tool ever asked you to log the full text of a request body by default, for good reason. Agent telemetry inverts this: the prompt is the input, the completion is the behavior, and you frequently cannot debug a bad agent decision without seeing exactly what the model saw. This collides head-on with privacy and PII concerns, which is why mature setups support content redaction and sampling at the exporter, capture everything in dev, capture references and hashes in prod, and make that toggle explicit.

Model and prompt versioning. When a vendor silently updates a model, your agent's behavior can shift with zero code change. Telemetry that records the exact model build and prompt version is the only way to correlate a quality regression with its real cause. This is the runtime half of versioning agents and their tools.

Evaluation scores as telemetry. The frontier practice is attaching quality judgments, from an LLM-as-judge, a heuristic, or human review, back onto the trace as attributes. That turns observability from "what happened" into "how good was what happened," and it's the bridge between your telemetry pipeline and your eval pipeline.

Where the Standard Is Still Broken

Anyone selling you "full agent observability, fully standardized" is overstating it. Three gaps are real and worth naming.

Multi-agent traces don't propagate cleanly. The moment one agent calls another, the supervisor-agent pattern, a agent mesh, or any A2A handoff, you need trace context to cross the boundary so the child agent's spans nest under the parent's task. Today that propagation is inconsistent. Different frameworks break the trace, start a fresh root, or drop the linkage entirely, and you're left correlating by timestamp like it's 2009. As agent-to-agent protocols standardize, context propagation has to be part of the protocol, not an afterthought, and it largely isn't yet.

Outcome attribution is unsolved. Per-outcome pricing assumes you can causally tie a business result to the agent run that produced it. Telemetry captures the run; it does not yet capture, in any standard way, whether the outcome was actually achieved and how much of it the agent deserves credit for. This is the single biggest hole between today's telemetry standards and the economics the GaaS model promises.

Semantic drift in the conventions themselves. The GenAI conventions are still marked experimental in places, and attribute names have changed between releases. If you hard-code against a snapshot, an upgrade can quietly break your dashboards. Pin versions, watch the changelog, and treat the spec as a moving target for at least another release cycle.

The Vendor Lock-In Trap Hiding in Your Tracing Library

Here's the trap most teams walk into without noticing.

A vendor, say a slick agent-observability startup, hands you a one-line SDK. Wrap your agent, get gorgeous traces, beautiful waterfall views, zero config. It feels like a gift. And it is, right up until you want to leave, route the same data to your security team's SIEM, or correlate agent traces with the rest of your infrastructure in the tool your SRE team already pays for. Then you discover the SDK emits a proprietary schema, and your two years of telemetry history is hostage.

The defense is architectural, and it's cheap if you do it on day one: instrument against the OpenTelemetry API, export through the OTel Collector, and treat vendors as interchangeable backends behind it. The Collector is the unsung hero here, a single, vendor-neutral pipe that receives OTel data and fans it out to any number of destinations. Want to send traces to Phoenix for eval, metrics to Prometheus, and a sampled copy to a managed APM? That's a config file, not a re-instrumentation project. The CNCF's OpenTelemetry Collector documentation lays out the receiver-processor-exporter model that makes this possible.

The same neutrality logic runs through the whole stack, it's why building a multi-model agent without vendor lock-in and choosing open-source vs. proprietary frameworks are recurring questions. Telemetry is just the place where lock-in is easiest to sleepwalk into, because the proprietary path is genuinely the path of least resistance on day one. The bill comes later.

Telemetry as the Billing Substrate for GaaS

Step back and the strategic picture sharpens. In the SaaS era, telemetry was an operational concern owned by engineering. In the GaaS era, telemetry is also a financial and contractual artifact.

If you sell an agent at a fixed monthly fee, loose telemetry is survivable. The moment you price per task or per outcome, your telemetry pipeline becomes the meter that generates the invoice, and your customer's basis for disputing it. When a buyer asks "why did this month cost 40% more," the answer lives in your spans: more tasks, longer reasoning chains, a model-version change, a retry storm from a flaky integration. Without per-task cost attribution baked into the telemetry, you're guessing at your own unit economics, and analysts at firms like a16z have argued that per-outcome pricing is where agent value capture is heading, which only works if the measurement underneath it is trustworthy.

This reframes the standards question. OpenTelemetry adoption isn't just engineering hygiene; it's what makes per-task cost legible to both sides of a contract. A neutral, auditable, model-agnostic record is exactly what you want when money rides on the numbers. Proprietary telemetry you can't export is a liability the day a customer's procurement team asks to see the meter.

A Practical Instrumentation Playbook

For an operator standing up an agent today, the path is more settled than the debates suggest:

1. Adopt OpenTelemetry as the substrate now, even though the GenAI conventions are still firming up. The envelope is stable; you want to be on it before you have years of data to migrate.
2. Use auto-instrumentation for the boring 80%, there are OTel-native libraries that hook the major model SDKs and frameworks automatically. Don't hand-roll what's already conventionalized.
3. Add manual spans for what's yours, your business logic, your decision points, your domain tools. Auto-instrumentation can't know what a "successful onboarding" means in your product.
4. Make cost a first-class attribute on every model span. Compute it at capture time. A trace without cost is half a trace in a per-task world.
5. Route everything through the Collector, not directly into a vendor SDK, so backends stay swappable.
6. Decide your content-capture policy deliberately, full prompts in dev, redacted or referenced in prod, and enforce it at the exporter, not in scattered application code.
7. Pin your semconv version and watch the changelog, because the spec is still moving.

None of this is exotic. It's mostly the discipline of treating telemetry as infrastructure rather than a feature you bolt on after the agent already misbehaves in production.

Insights Most People Overlook

The trace is the only artifact that survives a non-reproducible bug. Agents are stochastic; the failure you saw at 2 a.m. may never recur on demand. In deterministic software you can re-run to reproduce. With agents, if you didn't capture the full trace, prompt, completion, tool I/O, the lot, that bug is gone forever and you're debugging from a screenshot. Telemetry isn't a debugging aid for agents; for a large class of issues, it's the only evidence that will ever exist.

Token telemetry is a leading indicator of quality decay, not just cost. Teams watch token counts as a billing metric and miss that creeping input-token growth usually means context pollution, the agent dragging more and more irrelevant history into each call. That degrades reasoning quality before it shows up as a wrong answer. A rising token trend on a stable task is an early warning that something in your context management is rotting.

The most valuable telemetry attribute is the one no standard defines: "did the agent achieve the user's goal?" Everything in the GenAI conventions describes mechanism, calls, tokens, latency. The thing the business actually cares about, task success, has no standard representation because it's domain-specific. The teams getting real value are the ones defining their own success attribute and attaching it to the root span, knowingly stepping outside the standard because the standard can't follow them there yet.

Sampling strategy is where agent telemetry and classic APM violently disagree. Standard tracing samples aggressively, keep 1%, the rest is redundant. Agent traces are the opposite: the interesting ones are the rare, weird, expensive episodes, and uniform sampling throws exactly those away. You want tail-based sampling that keeps the slow, costly, error-laden, or low-eval-score traces and discards the boring successes. Importing APM sampling defaults into an agent system is a quiet way to blind yourself to your worst failures.

Standardization will consolidate faster than the framework wars suggest, because the buyers are forcing it. The frameworks may keep fragmenting, but enterprise procurement and security teams will not tolerate per-vendor telemetry silos for autonomous systems they're legally accountable for. That pressure, more than any spec committee, is what will make OTel the default. The standard isn't winning because it's the best design; it's winning because it's the only one a CISO can sign off on.

References

• OpenTelemetry GenAI Semantic Conventions, OpenTelemetry Documentation
• OpenTelemetry Collector, OpenTelemetry Documentation
• The Pricing of AI and the End of Per-Seat Software, Andreessen Horowitz (a16z)