AI agent observability is becoming causal evidence

A colorful trace can show that an agent called a model and three tools. It still may not explain why the wrong customer record changed, which policy allowed it, whether the tool committed the action or how the final state was verified. Production observability is moving from activity capture toward evidence that can reconstruct cause and outcome.

Evidence confidence97%
Hype riskHigh
Adoption stageRapid production adoption across OpenTelemetry, cloud agent platforms and evaluation systems
The 60-second answer

What is happening?

An agent trace should let an operator answer six questions without guessing: which user or service started the task, which software and model versions ran, what information the agent saw, what actions it proposed, what the controlled systems actually executed and what the final authoritative state became. Most current tracing products are good at the middle of that chain. They show prompts, completions, retrieval, tool calls and latency. The difficult gaps sit at the boundaries: authorization decisions, queue and subagent propagation, memory revisions, idempotency, database commits, external-system receipts and later user feedback. A production observability design therefore needs more than spans. It needs stable identities, versioned references, normalized action records, protected outcome evidence, evaluation labels and retention rules. Hidden chain-of-thought is neither required nor desirable. The aim is to reconstruct externally observable decisions and consequences while collecting the minimum sensitive content needed for diagnosis.

Why now

Why this trend is moving

  • 01OpenTelemetry now maintains dedicated GenAI semantic conventions for agent, workflow, tool, retrieval, model and evaluation telemetry.
  • 02OpenAI's Agents SDK traces model turns, tools, handoffs, guardrails and voice operations, with explicit controls for sensitive content.
  • 03Google Cloud Trace, Amazon Bedrock AgentCore and Microsoft Foundry expose agent-specific trace views built around OpenTelemetry-compatible data.
  • 04MLflow, LangSmith, Phoenix and OpenInference are joining traces with evaluation scores, annotations, datasets and experiments.
  • 05W3C Trace Context gives distributed services a portable correlation mechanism, but agent workflows also need semantic continuity across queues, subagents and long-running tasks.
  • 06Tool-using agents create side effects outside the model runtime, so a model span alone cannot establish what was authorized or committed.
  • 07Production teams are confronting telemetry cost, privacy, sampling and retention limits at the same time that traces are becoming more detailed.
What it changes

What this means in practice

  • A trace timeline shows order; causal evidence links each consequential step to the inputs, version, authority and state transition that made it possible.
  • Model, retrieval, tool, policy, memory and outcome events need stable semantic fields so they remain comparable across frameworks and backends.
  • Tool-call arguments should be captured after deterministic normalization, alongside authorization and execution results, rather than only as model-generated text.
  • Long-running tasks, queues and subagents must propagate trace and task identity without trusting caller-supplied baggage as authorization evidence.
  • Outcome verification should read the authoritative downstream system after execution; a successful HTTP response or fluent assistant message is not enough.
  • Sampling should preserve rare failures, policy denials and expensive side effects even when ordinary successful traces are sampled aggressively.
  • Privacy, redaction, access control and retention are part of the instrumentation contract because traces can contain prompts, customer data, credentials and proprietary logic.
  • Evaluation scores and human feedback should attach to the exact trace, span, version and outcome they assessed.
Engineering Lens

What the headline leaves out

This is the practical technical view: how the system is put together, where it can fail, and what a real deployment asks from the team running it.

01

How it is built

A production observability path begins with an evidence contract for each workflow: required identities, versions, actions, policy decisions, state changes and postconditions. The runtime creates a root task identifier and propagates W3C trace context across services, queues and subagents. Instrumentation emits spans for model inference, retrieval, memory reads and writes, guardrails, tool proposals, normalized action requests, policy checks, execution and handoff. An OpenTelemetry Collector or equivalent gateway receives the signals, applies schema normalization, redaction, cardinality controls, sampling and routing, then exports operational telemetry to one or more backends. Consequential actions also write protected evidence references containing request digests, authorization decision IDs, idempotency keys, downstream receipts and state revisions. A reconciliation service checks the authoritative system after the action and attaches the observed postcondition. Evaluation workers add deterministic checks, model-based scores or human annotations. Incident workflows can then move from an alert to the exact causal graph and create a regression dataset from confirmed failures.

02

How inference behaves

Distributed trace context supplies trace and parent identifiers, but continuity is lost when an agent framework invents local run IDs, drops context at an asynchronous boundary or starts a subagent without links. The instrumentation layer must map framework events into a canonical span model and preserve links when a strict parent-child tree does not match reality. Every span should identify the application release, workflow, agent, model and instrumentation version. Model spans can record provider, requested and returned model, token usage, timing, output type and content hashes. Full prompt or response capture should be opt-in and redacted. Retrieval spans should record source IDs, index or corpus revision, query, filters and result references. Tool spans should distinguish proposal, approval, execution and postcondition. Memory writes need old and new revision references. Logs and evaluation events carry the same trace and span IDs so they can be joined without copying sensitive payloads into every signal.

03

What the tests can miss

A credible observability evaluation measures trace continuity across synchronous and asynchronous boundaries, semantic coverage, version capture, normalized tool-argument fidelity, authorization linkage, state-lineage completeness, outcome-verification coverage, root-cause localization time, failure-retention probability, export loss, privacy leakage, instrumentation overhead, cross-backend portability and complete cost per resolved incident. The test corpus should include dropped context at queues, duplicate retries, parallel tools, cancelled tasks, subagent fan-out, model fallback, stale retrieval, memory overwrite, policy denial, partial tool success, downstream timeout after commit, idempotent replay, malformed telemetry, collector backpressure, exporter outage, PII in prompts, credential-like strings, high-cardinality attacks and successful-looking responses whose authoritative outcome is wrong. The benchmark should require an investigator to reconstruct the failure from retained evidence, not merely confirm that a trace exists.

04

What deployment involves

Start with three workflows that combine high volume, real tool use and known operational pain. Define a canonical event and span contract before choosing a dashboard. Instrument the deterministic orchestration, tool gateway and outcome reconciliation first; provider auto-instrumentation can fill in model details later. Route telemetry through a collector so redaction, sampling, schema migration and multi-backend export remain outside application code. Record application, prompt, policy, tool-schema, model and dataset versions. Use tail or policy-aware sampling to retain failures, denials, costly runs and side effects. Keep protected action evidence separate from broad developer trace access. Build trace-derived regression datasets only from reviewed incidents. Expand coverage after measuring export loss, latency overhead, sensitive-data exposure and investigator success.

05

Where the risks sit

Agent telemetry is a high-value data set. It can contain user messages, retrieved documents, tool arguments, system prompts, tenant identifiers, internal URLs, tokens, business rules and security decisions. Default to metadata and stable references; enable content capture only for a defined purpose and environment. Redact or tokenize before export, encrypt transport and storage, restrict trace access by role and tenant, audit exports, and keep credentials out of baggage, attributes and logs. Treat incoming trace context and baggage as untrusted correlation data, not identity or authorization. Prevent the model from selecting trace IDs, outcome status or evaluation labels. Protect collectors against denial of service and high-cardinality input. Separate operational debugging data from immutable action or compliance evidence, because broad observability tools often permit mutation, deletion or short retention.

06

What it really costs

The cost includes instrumentation engineering, collector compute, network egress, backend ingestion, indexing, storage, evaluator calls, protected evidence storage and investigator time. Capturing every prompt and token-rich response can make trace volume grow faster than request volume. High-cardinality attributes also increase index cost without improving diagnosis. A better design captures compact structured metadata for all runs, retains complete payloads only for approved samples or incidents, and stores large artifacts once behind protected references. Economics should be measured as complete observability cost per verified resolved incident and as prevented recurrence, not as price per gigabyte alone. A cheaper telemetry bill that misses the rare side effect responsible for customer harm is false economy.

07

What the evidence supports

The evidence supports a real standardization and product shift, but it does not show that a single agent-observability schema has stabilized. OpenTelemetry's GenAI conventions are moving quickly, and cloud or framework trace formats still differ. Current platforms reliably expose model calls, tools, latency, tokens and errors; support for authorization decisions, memory revisions, cross-agent lineage and authoritative postconditions is less consistent. Evaluation layers help answer whether an output was useful, but an evaluator score is another observation with its own model, prompt and uncertainty. The practical conclusion is to use OpenTelemetry-compatible plumbing and current GenAI conventions while owning a small canonical evidence model for the business actions that matter. Build adapters around that contract, version it, and keep outcome truth outside the language model and trace viewer.

How it works in practice

Agent observability becomes operationally useful when a trace can connect identity, versioned context, action authority, execution and authoritative outcome without turning prompts or hidden reasoning into an uncontrolled sensitive-data store.

Architecture Constraints Benchmarks Security Deployment
The full system

How the parts work together

The headline technology is only one part of the product. Reliability, security and cost are usually decided by the handoffs around it.

  1. 1

    Define the evidence contract

    List the identities, versions, action records, policy decisions, state transitions and postconditions required to explain one workflow.

  2. 2

    Create and propagate execution context

    Issue root task, trace and session identifiers, then carry or link them across services, queues, retries and subagents.

  3. 3

    Instrument the real control path

    Emit structured spans for models, retrieval, memory, guardrails, tool proposals, authorization, execution and handoffs.

  4. 4

    Normalize and protect telemetry

    Use a collector gateway for schema mapping, redaction, cardinality control, sampling, buffering and multi-backend export.

  5. 5

    Record consequential action evidence

    Store normalized request digests, decision IDs, idempotency keys, downstream receipts and state revisions in a protected evidence plane.

  6. 6

    Reconcile authoritative outcomes

    Read the downstream source of truth after execution and attach the observed postcondition rather than trusting a model or transport success message.

  7. 7

    Evaluate, alert and investigate

    Join deterministic checks, quality evaluators, human feedback and incidents to the exact trace, span, version and outcome.

  8. 8

    Govern retention and learning

    Apply purpose-based retention, access control and deletion, then promote reviewed failures into regression datasets and release gates.

Back-of-the-envelope planning

Estimate the limits before the demo

These equations are planning tools rather than substitutes for testing. They help expose a design that is unlikely to fit its hardware, budget, reliability or risk limits.

Causal evidence completeness

C_e = \frac{\sum_i w_i p_i}{\sum_i w_i}

Each required evidence element i has weight w_i and presence score p_i between 0 and 1. High-volume model spans should not hide missing authorization or outcome evidence with larger business weight.

  • A support-answer trace may weight retrieval and response evidence heavily.
  • A payment or account-change trace should weight authorization, normalized arguments, idempotency and postcondition more heavily than prompt capture.
  • Report completeness by workflow class instead of averaging unlike operations.

Probability that sampling misses every rare failure

P_{miss} = (1-p)^n

If each of n independent failure instances has probability p of being retained, the probability that none is retained falls exponentially. The independence assumption is fragile when sampling is correlated by route, tenant or collector failure.

  • At p = 0.10 and n = 3, missing all three is 72.9 percent.
  • Policy-aware tail sampling should force retention for denials, errors and consequential side effects rather than relying on random probability.
  • Export outages can invalidate the formula because failures may disappear together.

Complete cost per resolved incident

C_r = \frac{C_{instrument}+C_{ingest}+C_{store}+C_{eval}+C_{people}}{N_{verified\ resolved}}

The denominator counts incidents whose root cause was verified and whose corrective action was confirmed. Cheap storage with poor diagnostic yield can produce a worse result than selective high-quality evidence.

  • Include analyst time spent opening incomplete traces and reproducing missing context.
  • Separate ordinary observability cost from protected evidence retention for high-risk actions.
  • Track recurrence after fixes so a fast but incorrect diagnosis is not counted as success.
The central distinction

A timeline is not yet an explanation

Most trace viewers are excellent at showing order. A model generated a tool call, the tool returned JSON, another model produced a final answer. That sequence can still leave the root cause unresolved. The wrong tenant may have been selected before the trace began. A stale policy cache may have approved the call. The tool may have committed a change after the client timed out. The assistant may then have announced failure even though the database changed.

Causal evidence adds the missing links. It identifies the runtime and release, preserves the task and delegation context, records normalized arguments, connects the policy decision, captures the execution receipt and checks the authoritative state. Each link answers a different question. Combining them is what lets an investigator distinguish model error, orchestration error, authorization failure, downstream ambiguity and misleading presentation.

The practical test is simple: can a second engineer, who did not build the agent, explain the failure and verify the final state from the retained record? If the answer requires guessing from prompt text or rerunning production traffic, the observability contract is incomplete.

  • Sequence shows when operations occurred.
  • Causality connects operations to inputs, versions, authority and state.
  • Outcome evidence proves what the external system finally recorded.
  • Evaluation adds a judgment, not ground truth by itself.
Distributed execution

Trace context has to survive queues, retries and subagents

W3C Trace Context gives HTTP services a portable traceparent and tracestate format. Agent workflows often travel through places where a simple parent-child request chain breaks down: message queues, scheduled work, parallel tools, resumable sessions, human approvals and subagents that continue after the initiating process exits.

Use parent-child relationships when one operation directly contains another. Use span links when a consumer processes a queued message later, when several upstream events contribute to one action, or when a retry belongs to the same logical task but not the same call stack. Keep a separate stable task or workflow identifier so trace rotation and long retention do not erase the business unit of work.

Baggage can carry correlation values, but it travels through network headers and lacks built-in integrity protection. Treat it as untrusted metadata. Tenant, principal and authorization state should come from authenticated context or signed evidence, then be recorded as protected attributes rather than accepted because a caller placed them in baggage.

  • Propagate W3C trace context at supported protocol boundaries.
  • Use links for asynchronous and many-to-many relationships.
  • Maintain a stable task ID across trace segments.
  • Never use baggage as proof of identity or permission.
Model telemetry

You can debug model behavior without collecting hidden reasoning

Useful model telemetry includes provider, requested model, returned model, endpoint, latency, token usage, finish reason, tool schema version, output type, retry count and a reference to the exact prompt template and application release. Those fields explain many regressions without storing every user message or internal reasoning token.

Prompt and response content may be necessary for selected investigations or evaluation datasets. Capture should be explicit, purpose-bound and redacted before export. A content hash or protected object reference can prove which artifact was used while keeping the full payload in a more restricted store. Audio, images and large documents deserve the same separation because embedding them in span attributes creates cost, privacy and size problems.

Hidden chain-of-thought is not an observability requirement. It may be unavailable, unreliable as an explanation, or intentionally protected by the provider. Diagnose from externally visible inputs, model outputs, tool proposals, constraints and outcomes. That record is easier to standardize and closer to what the system actually executed.

  • Record exact model and application versions.
  • Capture token, latency, retry and finish metadata.
  • Reference prompts and large artifacts by version or digest.
  • Make full content capture opt-in and access controlled.
Consequential actions

One tool call usually contains four different events

A model first proposes an action. Deterministic code parses and normalizes its arguments. A policy or approval service decides whether the action may proceed. The tool adapter then executes against an external system. Compressing those stages into one span called tool_call hides where responsibility changed.

Record the proposed arguments and the normalized request separately. Attach tool-schema, policy and adapter versions. The authorization decision should have its own identifier, reason category and prerequisite state. Execution should record idempotency key, request digest, downstream correlation ID, transport result and commit receipt. Credentials and secret headers stay out of the trace.

Finally, reconcile the postcondition. An HTTP 200 can contain a rejected business operation. A timeout can occur after a successful commit. A queue acknowledgment may precede execution by minutes. Read the source of truth and attach what exists now: order ID, record revision, payment state, permission set or explicit absence.

  • Separate proposal, normalization, authorization and execution.
  • Record idempotency and downstream correlation identifiers.
  • Distinguish transport success from business success.
  • Verify the postcondition from the authoritative system.
Changing context

Retrieval and memory need versioned lineage

A retrieval span that says vector_search returned five documents is rarely enough. Investigators need the data source, corpus or index revision, query after transformation, filters, embedding or reranker version, result identifiers and scores. Full document text can remain in the governed source system and be linked by stable references.

Memory creates a harder problem because it changes what later runs see. A write should identify the previous revision, proposed content, validation result, new revision and retention class. A read should identify which revision influenced the run. Without those links, a bad answer may look like a model regression when the real cause was a stale or poisoned memory entry created days earlier.

The same principle applies to prompt templates, tool schemas, policies and feature flags. Observability becomes far more useful when every mutable input is a versioned artifact rather than an unstructured string copied into a trace.

  • Record source and index revisions for retrieval.
  • Link memory reads and writes to immutable revisions.
  • Capture query transformations and filters.
  • Version prompts, tools, policies and feature flags.
Economics

Random sampling is weakest where the failures are rarest

Head sampling decides before the request outcome is known. It is cheap and predictable, but it can discard the one run that later produces a policy denial, expensive retry storm or damaging side effect. Tail sampling waits for more of the trace and can retain errors, latency outliers or matching attributes. It also needs buffering, consistent routing and enough memory to assemble traces.

Agent workflows add business-aware conditions. Preserve every consequential write, human escalation, policy denial, evaluator failure and ambiguous postcondition. Sample ordinary successful reads more aggressively. Keep a compact all-traffic metric and event layer so low trace retention does not erase volume, latency or error-rate trends.

Retention should follow purpose. Developers may need detailed content for days, security teams may need protected decision evidence longer, and user-deletion obligations may require targeted removal. One universal retention period usually grants too much access to some data and destroys other evidence too early.

  • Use policy-aware retention for side effects and failures.
  • Monitor collector drops and incomplete traces.
  • Separate detailed payload retention from compact metadata retention.
  • Test deletion and legal-hold behavior before production.
Quality signals

Attach evaluations to evidence, not to screenshots

Traces answer what happened. Evaluations estimate whether the answer, retrieval, tool choice or outcome met a criterion. The evaluation must point to the exact trace and span, application version, evaluator version, rubric and judge model. Otherwise a score cannot be reproduced after the system changes.

Start with deterministic checks where possible: schema validity, allowed tool, argument constraints, citation presence, postcondition match and policy outcome. Use model-based evaluators for qualities that require judgment, then calibrate them against human labels and monitor disagreement. A judge explanation is diagnostic material, not unquestioned truth.

Reviewed production failures can become datasets. Preserve the original evidence, create a minimized test case and run candidate releases against the same acceptance criteria. This closes the loop from incident to regression test without treating all raw traffic as training data.

  • Version evaluator prompt, model and rubric.
  • Prefer deterministic checks for deterministic properties.
  • Calibrate model judges against human review.
  • Promote confirmed incidents into governed regression datasets.
Telemetry risk

The observability system can become the largest sensitive database in the stack

Prompt capture, retrieved content and tool arguments can recreate customer records, secrets and internal workflows even when the production application stores little. Auto-instrumentation defaults should be reviewed line by line. A framework may capture model or tool inputs that the central platform team never intended to export.

Redact near the source or at a trusted collector before data crosses organizational boundaries. Use allowlists for attributes, size limits for payloads and cardinality budgets for user-controlled values. Encrypt transport and storage, isolate tenants, restrict export, log access and separate broad developer traces from security or compliance evidence.

Integrity matters as much as confidentiality. Attackers can inject misleading attributes, choose high-cardinality IDs, force trace volume or tamper with mutable dashboards. Protected action evidence should carry digests, trusted timestamps or append-only controls appropriate to the risk. Do not let the agent declare its own success, severity or evaluation score.

  • Review every auto-instrumented field.
  • Redact before external export.
  • Apply attribute and cardinality allowlists.
  • Protect evidence integrity separately from dashboard convenience.
Moving standards

Own a canonical evidence model while conventions evolve

OpenTelemetry provides the strongest common transport, context and signal model available for this work. Its GenAI conventions are still developing and have already moved into a dedicated repository. Provider and framework integrations do not all emit the same operations, attributes or content structures.

Choose a small internal contract for the fields that carry operational meaning: workflow, task, agent, release, model, prompt version, tool, normalized action, principal reference, decision ID, state revision, postcondition and evaluation. Map incoming framework spans into that contract at the collector or adapter layer. Preserve original attributes where useful, but do not make dashboards depend directly on unstable experimental names.

Version the mapping and test it with golden traces. A library upgrade that silently renames a span or stops capturing a tool result should fail an observability contract test before deployment. Export to more than one backend when portability or regulated retention justifies the cost.

  • Adopt OTLP and W3C context for portability.
  • Define a narrow internal evidence schema.
  • Version mappings from framework conventions.
  • Run golden-trace compatibility tests during upgrades.
Operations

Design the trace around the investigation that follows

A useful incident view starts from the user-visible symptom or external record, not from a model span. Operators need to search by order, case, task, tenant, downstream receipt or evaluation failure and then pivot into the trace. That requires indexed correlation fields chosen from real support and security workflows.

The evidence should show the earliest divergent state, not only the final exception. Compare the failing run with a known-good run of the same workflow and release. Highlight version differences, missing spans, altered retrieval sources, policy decisions, retries and postconditions. Root cause is often a combination: a model proposed an unusual argument, validation accepted it, policy lacked a condition and the adapter retried after an ambiguous timeout.

Measure investigator performance. Give engineers synthetic and historical incidents, then record whether they identify the correct component, authority path and final state within the target time. Observability is an operational capability, not a count of spans emitted.

  • Index identifiers used by support, security and operations.
  • Compare failing and known-good causal graphs.
  • Capture the first divergent state.
  • Test whether investigators reach a verified conclusion.
Test it properly

What a benchmark worth believing should report

A performance number means little unless the workload, system configuration and quality bar are fixed. This is the minimum record a team should keep.

MetricHow to measure itWhy it matters
Trace continuity rate Percentage of test workflows whose root task and trace relationships survive every service, queue, retry, handoff and subagent boundary. Broken context turns one incident into unrelated fragments.
Semantic coverage Weighted share of required model, retrieval, memory, tool, policy, execution and outcome fields present and valid. Span count can be high while decisive evidence is absent.
Version capture accuracy Agreement between trace metadata and deployed application, prompt, policy, tool-schema, model and dataset versions. Diagnosis and replay depend on knowing exactly what ran.
Normalized argument fidelity Exact match between the recorded normalized tool request and the request received by the downstream adapter. Model text is not the same as the executed action.
Authorization linkage Share of consequential actions with a resolvable decision ID, policy version, principal reference and prerequisite result. An action cannot be explained without its authority path.
State-lineage completeness Share of retrieval and memory operations linked to source, index or revision identifiers before and after mutation. Changing context often causes delayed and nonlocal failures.
Outcome-verification coverage Share of consequential actions followed by a read from the authoritative system and an attached postcondition. Transport and model success do not prove business success.
Root-cause localization time Median and p95 investigator time to identify the correct failure component and earliest divergent state in blinded exercises. This measures operational usefulness rather than data volume.
Failure retention rate Percentage of injected denials, errors, ambiguous commits and harmful outcomes retained under production sampling rules. Rare events are the reason detailed traces are needed.
Export completeness Difference between emitted and queryable spans, logs and evaluation events under normal load, backpressure and exporter failure. Silent telemetry loss creates false confidence.
Sensitive-data leakage rate Count and severity of prohibited values found in attributes, events, logs, baggage and exported payloads. Agent traces can reconstruct highly sensitive workflows.
Instrumentation overhead Change in p50, p95 and p99 latency, CPU, memory and network use with representative tracing and sampling enabled. Observability that destabilizes the agent creates its own incidents.
Portability score Percentage of required fields, links and evaluations preserved when exporting the same golden traces to each approved backend. Standards claims should survive a backend change.
Cost per verified resolved incident Total telemetry, evaluation and investigation cost divided by incidents whose root cause and corrective action were verified. Storage cost alone does not capture diagnostic value.
Product choices

Four sensible deployment patterns

01

Framework-native tracing

Where it fits
Small teams using one agent framework and one managed trace backend.
What you take on
Fastest setup, but framework IDs, schemas, retention and content defaults can create lock-in or blind spots at external action boundaries.
02

OpenTelemetry-first collector gateway

Where it fits
Multi-framework systems that need redaction, sampling, schema normalization and more than one backend.
What you take on
Adds collector operations and mapping work, but keeps telemetry policy outside application code and improves portability.
03

Dual-plane operations and evidence

Where it fits
Agents that perform customer, financial, administrative or security-relevant actions.
What you take on
Operational traces remain convenient and sampled while protected action evidence is narrower, more durable and more expensive to govern.
04

Regulated event-sourced action ledger

Where it fits
High-assurance workflows where every proposal, approval, state transition and postcondition must be independently reconstructable.
What you take on
Strongest accountability and replay, with the highest implementation, storage, privacy and schema-governance burden.
Lessons from the edge cases

Where projects usually go wrong

01

Broken asynchronous context

What you see: Queue consumers and subagents appear as unrelated traces.

What to do: Propagate task identity and trace context, then use span links for asynchronous relationships.

02

One span for the entire tool call

What you see: Investigators cannot separate model proposal, policy decision, adapter execution and postcondition.

What to do: Instrument each boundary and link them with stable action and decision identifiers.

03

Raw prompt capture by default

What you see: Trace storage accumulates customer data, secrets and costly payloads.

What to do: Default to metadata and references; enable redacted content capture only for approved purposes.

04

No release or prompt version

What you see: Two visually similar traces cannot be tied to the code or template that produced them.

What to do: Attach immutable release, prompt, tool-schema, policy and model identifiers.

05

Transport result treated as outcome

What you see: A timeout is labeled failure after commit, or HTTP success hides business rejection.

What to do: Reconcile the authoritative downstream state and record the postcondition.

06

Random sampling drops rare harm

What you see: Dashboards look healthy while the consequential failure has no trace.

What to do: Force retention for side effects, denials, evaluator failures and ambiguous outcomes.

07

Collector backpressure is invisible

What you see: Missing spans are mistaken for operations that never happened.

What to do: Monitor collector queues, drops, export retries and trace completeness.

08

High-cardinality attribute attack

What you see: Costs and index load spike after user-controlled values enter labels.

What to do: Apply allowlists, length limits, hashing and cardinality budgets before export.

09

Memory mutation lacks lineage

What you see: A later model failure cannot be connected to the earlier write that poisoned context.

What to do: Record previous and new memory revisions plus validation results.

10

Evaluator score loses provenance

What you see: A quality regression cannot be reproduced after judge or rubric changes.

What to do: Version evaluator model, prompt, rubric, code and target trace or span.

11

Trace context trusted as identity

What you see: Caller-supplied baggage influences tenant or authorization decisions.

What to do: Use authenticated identity for policy and treat trace metadata only as correlation.

12

Dashboard evidence is mutable or short-lived

What you see: The record needed for a dispute or incident disappears or changes.

What to do: Store narrow protected action evidence with appropriate integrity and retention controls.

Before release

A checklist you can actually use

  1. Name the business outcome and authoritative source of truth for each instrumented workflow.
  2. Define the required identities, versions, actions, decisions, state revisions and postconditions.
  3. Create separate root task, trace, session and action identifiers where their lifetimes differ.
  4. Propagate W3C trace context across supported synchronous boundaries.
  5. Use span links for queues, fan-in, fan-out, retries and resumable work.
  6. Treat baggage and caller-supplied trace fields as untrusted correlation metadata.
  7. Record application, prompt, model, tool-schema, policy and evaluator versions.
  8. Separate model proposal from normalized deterministic arguments.
  9. Link every consequential action to its authorization or approval decision.
  10. Use idempotency keys and downstream correlation identifiers.
  11. Verify postconditions from the authoritative external system.
  12. Record retrieval source, index and document revisions without duplicating unnecessary content.
  13. Record memory read and write lineage with immutable revisions.
  14. Default content capture to off and document every exception.
  15. Redact sensitive data before telemetry leaves the trusted boundary.
  16. Apply attribute allowlists, size limits and cardinality budgets.
  17. Design policy-aware sampling for errors, denials, side effects and ambiguous outcomes.
  18. Monitor collector backpressure, drops, retries and incomplete traces.
  19. Version and calibrate deterministic, model-based and human evaluations.
  20. Separate broad operational traces from protected durable evidence where risk requires it.
  21. Run golden-trace compatibility tests when frameworks or semantic conventions change.
  22. Measure investigator accuracy and root-cause localization time with blinded incidents.
  23. Turn reviewed failures into minimized regression datasets and release gates.
Plain-language definitions

Terms worth knowing

Trace
A related set of spans representing one distributed execution or request path.
Span
A timed operation with identity, parent or links, status, attributes and events.
Trace context
Portable identifiers and flags propagated between components so telemetry can be correlated.
Span link
A relationship to another span used when strict parent-child structure does not fit asynchronous or many-to-many work.
Baggage
Key-value context propagated alongside traces; useful for correlation but not integrity-protected authorization evidence.
Semantic convention
A shared naming and meaning contract for telemetry operations, attributes, metrics and events.
OTLP
The OpenTelemetry Protocol used to export traces, metrics and logs.
Head sampling
A trace-retention decision made near the start of execution before the final result is known.
Tail sampling
A retention decision made after enough spans or outcome information have been collected.
Cardinality
The number of distinct values an attribute can take, which strongly affects index cost and performance.
Postcondition
The authoritative state observed after an attempted action.
Causal evidence
Linked records sufficient to explain which inputs, versions, authority and state transitions produced an outcome.
Lineage
The versioned relationship between data or state read by a run and the revisions created or consumed.
Evaluation event
A versioned score, label or judgment attached to a specific trace or span.
Golden trace
A controlled reference execution used to test instrumentation, schema mapping and backend portability.
About the author

H. Omer Aktas

H. Omer Aktas is the independent editor and publisher of WTFIsTrending.com. He applies more than 30 years of operational, surveillance, analytics and systems experience from regulated casino environments to questions of evidence, controls, implementation risk and deployment reality.

Source trail · 116 references

Primary references and technical starting points

These sources support the architecture, runtime, benchmark and security claims. Vendor capabilities can change, so the article records the distinction between established evidence, measured product behavior and editorial interpretation.

  1. 01 OpenTelemetry documentationopentelemetry.io
  2. 02 OpenTelemetry conceptsopentelemetry.io
  3. 03 OpenTelemetry signalsopentelemetry.io
  4. 04 OpenTelemetry tracesopentelemetry.io
  5. 05 OpenTelemetry metricsopentelemetry.io
  6. 06 OpenTelemetry logsopentelemetry.io
  7. 07 OpenTelemetry baggageopentelemetry.io
  8. 08 OpenTelemetry context propagationopentelemetry.io
  9. 09 OpenTelemetry samplingopentelemetry.io
  10. 10 OpenTelemetry semantic conventionsopentelemetry.io
  11. 11 OpenTelemetry semantic conventions 1.43opentelemetry.io
  12. 12 OpenTelemetry general semantic conventionsopentelemetry.io
  13. 13 OpenTelemetry resource semantic conventionsopentelemetry.io
  14. 14 OpenTelemetry trace specificationopentelemetry.io
  15. 15 OpenTelemetry logs specificationopentelemetry.io
  16. 16 OpenTelemetry metrics specificationopentelemetry.io
  17. 17 OpenTelemetry protocol specificationopentelemetry.io
  18. 18 OpenTelemetry Collectoropentelemetry.io
  19. 19 OpenTelemetry Collector architectureopentelemetry.io
  20. 20 OpenTelemetry Collector configurationopentelemetry.io
  21. 21 OpenTelemetry Collector deploymentopentelemetry.io
  22. 22 OpenTelemetry Collector processorsopentelemetry.io
  23. 23 OpenTelemetry Collector receiversopentelemetry.io
  24. 24 OpenTelemetry Collector exportersopentelemetry.io
  25. 25 OpenTelemetry Collector scalingopentelemetry.io
  26. 26 OpenTelemetry security guidanceopentelemetry.io
  27. 27 OpenTelemetry sensitive-data guidanceopentelemetry.io
  28. 28 OpenTelemetry Collector configuration securityopentelemetry.io
  29. 29 OpenTelemetry Collector hosting securityopentelemetry.io
  30. 30 OpenTelemetry GenAI semantic conventions repositorygithub.com
  31. 31 OpenTelemetry core semantic conventions repositorygithub.com
  32. 32 OpenTelemetry Python GenAI instrumentationgithub.com
  33. 33 OpenTelemetry OpenAI Agents instrumentationgithub.com
  34. 34 OpenTelemetry Collector tail-sampling processorgithub.com
  35. 35 OpenTelemetry Collector redaction processorgithub.com
  36. 36 W3C Trace Context Recommendationw3.org
  37. 37 W3C Trace Context Level 2w3.org
  38. 38 W3C Baggage specificationw3.org
  39. 39 OpenAI Agents SDKopenai.github.io
  40. 40 OpenAI Agents SDK tracingopenai.github.io
  41. 41 OpenAI Agents SDK tracing referenceopenai.github.io
  42. 42 OpenAI Agents SDK trace creationopenai.github.io
  43. 43 OpenAI Agents SDK run configurationopenai.github.io
  44. 44 OpenAI Agents SDK usage accountingopenai.github.io
  45. 45 OpenAI Agents SDK configuration and sensitive loggingopenai.github.io
  46. 46 OpenAI Agents SDK voice tracingopenai.github.io
  47. 47 OpenAI Agents SDK guardrailsopenai.github.io
  48. 48 OpenAI Agents SDK handoffsopenai.github.io
  49. 49 Google Cloud Trace overviewcloud.google.com
  50. 50 Google Cloud Trace documentationcloud.google.com
  51. 51 Google Cloud Trace instrumentationcloud.google.com
  52. 52 Google Cloud Trace explorercloud.google.com
  53. 53 Google Cloud agent tracingcloud.google.com
  54. 54 Google Cloud agent evaluationcloud.google.com
  55. 55 Google Cloud multimodal trace datacloud.google.com
  56. 56 Google Cloud Trace quotascloud.google.com
  57. 57 Google Cloud Trace pricingcloud.google.com
  58. 58 Google Cloud Trace release notescloud.google.com
  59. 59 Amazon Bedrock AgentCore observabilitydocs.aws.amazon.com
  60. 60 Amazon Bedrock AgentCore observability quickstartdocs.aws.amazon.com
  61. 61 Amazon Bedrock AgentCore observability configurationdocs.aws.amazon.com
  62. 62 Amazon Bedrock AgentCore generated telemetrydocs.aws.amazon.com
  63. 63 Amazon Bedrock AgentCore trace viewingdocs.aws.amazon.com
  64. 64 Amazon Bedrock AgentCore runtime observabilitydocs.aws.amazon.com
  65. 65 Amazon Bedrock agent trace eventsdocs.aws.amazon.com
  66. 66 Amazon Bedrock agent troubleshootingdocs.aws.amazon.com
  67. 67 Amazon Bedrock AgentCore code-interpreter observabilitydocs.aws.amazon.com
  68. 68 Amazon Bedrock AgentCore memory observabilitydocs.aws.amazon.com
  69. 69 Microsoft Foundry agent tracing overviewlearn.microsoft.com
  70. 70 Microsoft Foundry tracing setuplearn.microsoft.com
  71. 71 Microsoft Foundry framework tracinglearn.microsoft.com
  72. 72 Microsoft Foundry client-side tracinglearn.microsoft.com
  73. 73 Microsoft Foundry trace data handlinglearn.microsoft.com
  74. 74 Microsoft Foundry observability conceptslearn.microsoft.com
  75. 75 Microsoft Foundry monitoring dashboardlearn.microsoft.com
  76. 76 Microsoft Foundry external-agent registrationlearn.microsoft.com
  77. 77 Azure Monitor OpenTelemetry overviewlearn.microsoft.com
  78. 78 Azure Monitor distributed tracinglearn.microsoft.com
  79. 79 MLflow agent tracingmlflow.org
  80. 80 MLflow trace conceptsmlflow.org
  81. 81 MLflow tracing integrationsmlflow.org
  82. 82 MLflow tracing quickstartmlflow.org
  83. 83 MLflow automatic tracingmlflow.org
  84. 84 MLflow users and sessionsmlflow.org
  85. 85 MLflow OpenAI tracingmlflow.org
  86. 86 MLflow AI Gateway tracingmlflow.org
  87. 87 MLflow production tracingmlflow.org
  88. 88 MLflow trace searchmlflow.org
  89. 89 LangSmith observabilitydocs.langchain.com
  90. 90 LangSmith tracing quickstartdocs.langchain.com
  91. 91 LangSmith observability conceptsdocs.langchain.com
  92. 92 LangSmith trace viewerdocs.langchain.com
  93. 93 LangSmith API tracingdocs.langchain.com
  94. 94 LangSmith LLM observability tutorialdocs.langchain.com
  95. 95 LangChain agent observabilitydocs.langchain.com
  96. 96 LangGraph observabilitydocs.langchain.com
  97. 97 LangSmith trace filteringdocs.langchain.com
  98. 98 LangSmith feedback conceptsdocs.langchain.com
  99. 99 OpenInference repositorygithub.com
  100. 100 OpenInference specificationgithub.com
  101. 101 Arize Phoenixarize.com
  102. 102 Phoenix tracing architecturearize.com
  103. 103 Phoenix tracing quickstartarize.com
  104. 104 Phoenix tracing how-toarize.com
  105. 105 Phoenix evaluations quickstartarize.com
  106. 106 Phoenix annotations and evaluationsarize.com
  107. 107 Phoenix privacy controlsarize.com
  108. 108 Phoenix evaluation frameworkarize.com
  109. 109 NIST AI Risk Management Frameworknist.gov
  110. 110 NIST AI RMF Generative AI Profilenvlpubs.nist.gov
  111. 111 NIST SP 800-92 log managementcsrc.nist.gov
  112. 112 NIST SP 800-61 incident responsecsrc.nist.gov
  113. 113 NIST SP 800-53 audit and accountability controlscsrc.nist.gov
  114. 114 OWASP Agentic AI Threats and Mitigationsgenai.owasp.org
  115. 115 OWASP Top 10 for LLM Applicationsgenai.owasp.org
  116. 116 OWASP Logging Cheat Sheetcheatsheetseries.owasp.org