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.
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 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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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
Define the evidence contract
List the identities, versions, action records, policy decisions, state transitions and postconditions required to explain one workflow.
- 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
Instrument the real control path
Emit structured spans for models, retrieval, memory, guardrails, tool proposals, authorization, execution and handoffs.
- 4
Normalize and protect telemetry
Use a collector gateway for schema mapping, redaction, cardinality control, sampling, buffering and multi-backend export.
- 5
Record consequential action evidence
Store normalized request digests, decision IDs, idempotency keys, downstream receipts and state revisions in a protected evidence plane.
- 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
Evaluate, alert and investigate
Join deterministic checks, quality evaluators, human feedback and incidents to the exact trace, span, version and outcome.
- 8
Govern retention and learning
Apply purpose-based retention, access control and deletion, then promote reviewed failures into regression datasets and release gates.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
| Metric | How to measure it | Why 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. |
Four sensible deployment patterns
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.
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.
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.
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.
Where projects usually go wrong
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
A checklist you can actually use
- Name the business outcome and authoritative source of truth for each instrumented workflow.
- Define the required identities, versions, actions, decisions, state revisions and postconditions.
- Create separate root task, trace, session and action identifiers where their lifetimes differ.
- Propagate W3C trace context across supported synchronous boundaries.
- Use span links for queues, fan-in, fan-out, retries and resumable work.
- Treat baggage and caller-supplied trace fields as untrusted correlation metadata.
- Record application, prompt, model, tool-schema, policy and evaluator versions.
- Separate model proposal from normalized deterministic arguments.
- Link every consequential action to its authorization or approval decision.
- Use idempotency keys and downstream correlation identifiers.
- Verify postconditions from the authoritative external system.
- Record retrieval source, index and document revisions without duplicating unnecessary content.
- Record memory read and write lineage with immutable revisions.
- Default content capture to off and document every exception.
- Redact sensitive data before telemetry leaves the trusted boundary.
- Apply attribute allowlists, size limits and cardinality budgets.
- Design policy-aware sampling for errors, denials, side effects and ambiguous outcomes.
- Monitor collector backpressure, drops, retries and incomplete traces.
- Version and calibrate deterministic, model-based and human evaluations.
- Separate broad operational traces from protected durable evidence where risk requires it.
- Run golden-trace compatibility tests when frameworks or semantic conventions change.
- Measure investigator accuracy and root-cause localization time with blinded incidents.
- Turn reviewed failures into minimized regression datasets and release gates.
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.
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.
- 01 OpenTelemetry documentationopentelemetry.io
- 02 OpenTelemetry conceptsopentelemetry.io
- 03 OpenTelemetry signalsopentelemetry.io
- 04 OpenTelemetry tracesopentelemetry.io
- 05 OpenTelemetry metricsopentelemetry.io
- 06 OpenTelemetry logsopentelemetry.io
- 07 OpenTelemetry baggageopentelemetry.io
- 08 OpenTelemetry context propagationopentelemetry.io
- 09 OpenTelemetry samplingopentelemetry.io
- 10 OpenTelemetry semantic conventionsopentelemetry.io
- 11 OpenTelemetry semantic conventions 1.43opentelemetry.io
- 12 OpenTelemetry general semantic conventionsopentelemetry.io
- 13 OpenTelemetry resource semantic conventionsopentelemetry.io
- 14 OpenTelemetry trace specificationopentelemetry.io
- 15 OpenTelemetry logs specificationopentelemetry.io
- 16 OpenTelemetry metrics specificationopentelemetry.io
- 17 OpenTelemetry protocol specificationopentelemetry.io
- 18 OpenTelemetry Collectoropentelemetry.io
- 19 OpenTelemetry Collector architectureopentelemetry.io
- 20 OpenTelemetry Collector configurationopentelemetry.io
- 21 OpenTelemetry Collector deploymentopentelemetry.io
- 22 OpenTelemetry Collector processorsopentelemetry.io
- 23 OpenTelemetry Collector receiversopentelemetry.io
- 24 OpenTelemetry Collector exportersopentelemetry.io
- 25 OpenTelemetry Collector scalingopentelemetry.io
- 26 OpenTelemetry security guidanceopentelemetry.io
- 27 OpenTelemetry sensitive-data guidanceopentelemetry.io
- 28 OpenTelemetry Collector configuration securityopentelemetry.io
- 29 OpenTelemetry Collector hosting securityopentelemetry.io
- 30 OpenTelemetry GenAI semantic conventions repositorygithub.com
- 31 OpenTelemetry core semantic conventions repositorygithub.com
- 32 OpenTelemetry Python GenAI instrumentationgithub.com
- 33 OpenTelemetry OpenAI Agents instrumentationgithub.com
- 34 OpenTelemetry Collector tail-sampling processorgithub.com
- 35 OpenTelemetry Collector redaction processorgithub.com
- 36 W3C Trace Context Recommendationw3.org
- 37 W3C Trace Context Level 2w3.org
- 38 W3C Baggage specificationw3.org
- 39 OpenAI Agents SDKopenai.github.io
- 40 OpenAI Agents SDK tracingopenai.github.io
- 41 OpenAI Agents SDK tracing referenceopenai.github.io
- 42 OpenAI Agents SDK trace creationopenai.github.io
- 43 OpenAI Agents SDK run configurationopenai.github.io
- 44 OpenAI Agents SDK usage accountingopenai.github.io
- 45 OpenAI Agents SDK configuration and sensitive loggingopenai.github.io
- 46 OpenAI Agents SDK voice tracingopenai.github.io
- 47 OpenAI Agents SDK guardrailsopenai.github.io
- 48 OpenAI Agents SDK handoffsopenai.github.io
- 49 Google Cloud Trace overviewcloud.google.com
- 50 Google Cloud Trace documentationcloud.google.com
- 51 Google Cloud Trace instrumentationcloud.google.com
- 52 Google Cloud Trace explorercloud.google.com
- 53 Google Cloud agent tracingcloud.google.com
- 54 Google Cloud agent evaluationcloud.google.com
- 55 Google Cloud multimodal trace datacloud.google.com
- 56 Google Cloud Trace quotascloud.google.com
- 57 Google Cloud Trace pricingcloud.google.com
- 58 Google Cloud Trace release notescloud.google.com
- 59 Amazon Bedrock AgentCore observabilitydocs.aws.amazon.com
- 60 Amazon Bedrock AgentCore observability quickstartdocs.aws.amazon.com
- 61 Amazon Bedrock AgentCore observability configurationdocs.aws.amazon.com
- 62 Amazon Bedrock AgentCore generated telemetrydocs.aws.amazon.com
- 63 Amazon Bedrock AgentCore trace viewingdocs.aws.amazon.com
- 64 Amazon Bedrock AgentCore runtime observabilitydocs.aws.amazon.com
- 65 Amazon Bedrock agent trace eventsdocs.aws.amazon.com
- 66 Amazon Bedrock agent troubleshootingdocs.aws.amazon.com
- 67 Amazon Bedrock AgentCore code-interpreter observabilitydocs.aws.amazon.com
- 68 Amazon Bedrock AgentCore memory observabilitydocs.aws.amazon.com
- 69 Microsoft Foundry agent tracing overviewlearn.microsoft.com
- 70 Microsoft Foundry tracing setuplearn.microsoft.com
- 71 Microsoft Foundry framework tracinglearn.microsoft.com
- 72 Microsoft Foundry client-side tracinglearn.microsoft.com
- 73 Microsoft Foundry trace data handlinglearn.microsoft.com
- 74 Microsoft Foundry observability conceptslearn.microsoft.com
- 75 Microsoft Foundry monitoring dashboardlearn.microsoft.com
- 76 Microsoft Foundry external-agent registrationlearn.microsoft.com
- 77 Azure Monitor OpenTelemetry overviewlearn.microsoft.com
- 78 Azure Monitor distributed tracinglearn.microsoft.com
- 79 MLflow agent tracingmlflow.org
- 80 MLflow trace conceptsmlflow.org
- 81 MLflow tracing integrationsmlflow.org
- 82 MLflow tracing quickstartmlflow.org
- 83 MLflow automatic tracingmlflow.org
- 84 MLflow users and sessionsmlflow.org
- 85 MLflow OpenAI tracingmlflow.org
- 86 MLflow AI Gateway tracingmlflow.org
- 87 MLflow production tracingmlflow.org
- 88 MLflow trace searchmlflow.org
- 89 LangSmith observabilitydocs.langchain.com
- 90 LangSmith tracing quickstartdocs.langchain.com
- 91 LangSmith observability conceptsdocs.langchain.com
- 92 LangSmith trace viewerdocs.langchain.com
- 93 LangSmith API tracingdocs.langchain.com
- 94 LangSmith LLM observability tutorialdocs.langchain.com
- 95 LangChain agent observabilitydocs.langchain.com
- 96 LangGraph observabilitydocs.langchain.com
- 97 LangSmith trace filteringdocs.langchain.com
- 98 LangSmith feedback conceptsdocs.langchain.com
- 99 OpenInference repositorygithub.com
- 100 OpenInference specificationgithub.com
- 101 Arize Phoenixarize.com
- 102 Phoenix tracing architecturearize.com
- 103 Phoenix tracing quickstartarize.com
- 104 Phoenix tracing how-toarize.com
- 105 Phoenix evaluations quickstartarize.com
- 106 Phoenix annotations and evaluationsarize.com
- 107 Phoenix privacy controlsarize.com
- 108 Phoenix evaluation frameworkarize.com
- 109 NIST AI Risk Management Frameworknist.gov
- 110 NIST AI RMF Generative AI Profilenvlpubs.nist.gov
- 111 NIST SP 800-92 log managementcsrc.nist.gov
- 112 NIST SP 800-61 incident responsecsrc.nist.gov
- 113 NIST SP 800-53 audit and accountability controlscsrc.nist.gov
- 114 OWASP Agentic AI Threats and Mitigationsgenai.owasp.org
- 115 OWASP Top 10 for LLM Applicationsgenai.owasp.org
- 116 OWASP Logging Cheat Sheetcheatsheetseries.owasp.org