It is Tuesday morning and your support agent did something. A refund was issued, a ticket was reclassified, a CRM row was updated, and a customer is now asking why. The on-call engineer opens the agent transcript. The final answer is clear. The tool calls are summarized in a vendor dashboard. Retrieval is logged somewhere else. The approval lives in a webhook log nobody owns. Four hours later, the team has reconstructed what should have been a query.

That is the operational state many agent deployments are drifting toward. Model behavior keeps improving. The evidence layer underneath it has not. Before a team gives an agent more autonomy, more tools, or more authority over real business state, it needs something unglamorous: a telemetry contract.

Final answers are not evidence

A chat transcript tells you what the agent said. It does not tell you what the agent did, why it chose to do it, what it read first, which model version answered, whether a guardrail fired, who approved the side effect, or what changed downstream. Those are the questions that matter in an incident, a compliance review, or a postmortem.

An agent run is a distributed computation across an orchestrator, one or more model providers, retrieval systems, tool executors, queues, and sometimes a human approval. If your evidence stops at the final response, you are reviewing the end of a movie and pretending you watched the whole thing.

The remedy is not "more logging." It is a contract: a shared schema for what every agent run must emit, in a form that survives service and vendor boundaries.

The ecosystem is moving this way

[OpenTelemetry's GenAI semantic conventions](https://opentelemetry.io/docs/specs/semconv/gen-ai/) define attributes, metrics, span and event names, span kinds, and units for generative AI systems. The page lists those conventions as being in development, and that qualifier matters. Teams should treat them as a converging contract, not a finalized cure-all. Still, adopting their shape is better than inventing a private taxonomy that no other tool understands. OpenTelemetry's broader writing on [LLM observability](https://opentelemetry.io/blog/2024/llm-observability/) makes the same point at the application layer: the unit of analysis is the path through prompts, retrieval, tools, and services, not just the response.

[W3C Trace Context](https://www.w3.org/TR/trace-context/) gives distributed systems a standard way to propagate trace identity across boundaries. For agents, that is the difference between an incident review that reads like engineering and one that reads like storytelling. If trace context breaks at the model provider, the tool executor, or the queue that schedules a side effect, you lose the thread tying a customer-visible outcome back to a specific run, prompt template, model version, and approval.

The [OpenInference specification](https://github.com/Arize-ai/openinference/tree/main/spec) is another signal: AI application traces are becoming an ecosystem concern, not just a vendor dashboard feature. Design your instrumentation through an adapter layer so operational evidence can emit in OpenTelemetry- or OpenInference-compatible shapes instead of being trapped in one UI.

There is also a governance angle. The [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) emphasizes governance, mapping, measurement, and management of AI risk. Telemetry is the evidence layer behind those verbs. Without it, "we manage AI risk" is a slide, not a practice.

What a useful agent trace contains

A telemetry contract answers one question: if this run is reviewed in six months, can a reasonable engineer reconstruct the decision? A workable contract captures:

  • Run and session identity. A stable run ID, session ID, and trace context across every service the run touches.
  • Request context without sensitive payloads. Who initiated the run, on whose behalf, in what tenant, with what scope. Identifiers, not raw user content.
  • Model calls and versions. Provider, model name, model version, sampling parameters, and prompt template ID. The template ID, not a rendered prompt full of secrets or PHI.
  • Retrieval steps. Inputs and outputs referenced by document IDs and relevance scores where safe, not copied source text by default.
  • Tool calls. Tool name, redacted arguments, and a result summary when raw payloads are large or sensitive.
  • Permission checks and approvals. Which policy was evaluated, what it returned, and who approved any human-in-the-loop step.
  • Evaluator and guardrail decisions. What checks ran, what they returned, and whether the run continued or stopped.
  • Side effects and rollback handles. A reference to external state that changed and, where possible, the handle needed to reverse it.
  • Cost, latency, and error dimensions as standard metrics, so one dashboard can answer what the agent costs and where it fails.

The point is not to log everything. The point is to log the right shape consistently, with names that map to standards where they exist.

What not to do

A telemetry contract should forbid as much as it requires:

  • Do not dump full prompts and tool outputs into traces by default. That is how PHI, secrets, and customer data end up in observability systems with the wrong retention policy.
  • Do not treat screenshots, Slack threads, or model-generated summaries as audit evidence. They are convenience, not record.
  • Do not rely solely on one vendor's proprietary trace view. If you cannot export the trace in an open shape, you do not own your operational evidence.
  • Do not collect sensitive fields without explicit retention, access control, and redaction rules. Observability should not become a shadow data store.

A Monday-morning checklist

1. Pick one production agent workflow and write its telemetry contract as a one-page document. List every span, event, and required attribute. 2. Adopt W3C Trace Context end to end. Verify the trace ID survives the model provider, tool executor, queue, and approval system. 3. Map span and attribute names to OpenTelemetry GenAI conventions where they apply today. Note where you are ahead of or beside the spec, and revisit as it matures. 4. Add redaction at the instrumentation boundary. Decide per field: drop, hash, tokenize, or pass through. Make the default conservative. 5. Define a replay test. Pick a finished run and ask whether an engineer who was not present could explain it from telemetry alone. 6. Tie the contract to governance. Reference the NIST AI RMF activities it supports so the work is visible as risk management, not just engineering hygiene.

The standard

Telemetry will not make an agent safe. It will not catch a bad policy by itself, replace evaluation, or substitute for human judgment on sensitive decisions. What it does is make the system legible. Legibility is the precondition for incident response, governance, evaluation, iteration, and any honest conversation about giving the agent more authority.

A practical rule of thumb: if a run cannot be replayed conceptually from telemetry, the agent is not ready for more autonomy. Fix the contract first. Then talk about scope.

Sources

Build Agents That Prove Their Work

If you are wiring agent workflows into real operations, Alchemic can help design the checkpoints, traces, and validation gates that keep automation honest.

Get the Field Guide - $10 ->