An agent can fail while every infrastructure dashboard remains green. The model may choose the wrong tool, loop through retries, use stale evidence, or complete a task that violates business intent. Observability must connect technical execution to the outcome the user expected.
The goal is not to store every prompt forever. It is to capture enough structured evidence to explain behavior, measure reliability, control cost, and improve the system under appropriate privacy rules.
Use a trace for the complete run
Create one trace per user-visible task and spans for context assembly, retrieval, model calls, policy checks, tool calls, human review, and finalization. Carry stable identifiers for workflow version, model, prompt, tenant, risk class, and evaluation cohort.
A trace should show where time and cost accumulated and which state transition changed the outcome.
Measure behavior, not only infrastructure
Infrastructure signals remain necessary, but agent operations need behavioral measures: task completion, escalation, incorrect tool selection, policy denial, loop termination, citation availability, and post-review correction.
- End-to-end completion and time-to-resolution
- Model and tool latency by operation
- Input and output tokens, retries, and estimated cost
- Tool error, denial, timeout, and compensation rates
- Human approval, correction, and override rates
- Evaluation failures by workflow and risk slice
Treat content capture as sensitive
Prompts, retrieved evidence, tool results, and completions may contain personal, confidential, or regulated information. Default to structured metadata and selectively capture content under explicit access, retention, and redaction controls.
Debug access should be auditable. Production telemetry should not become an easier route to sensitive data than the systems the agent uses.
Connect telemetry to evaluation
Sample real runs into an evaluation queue, especially policy denials, corrections, long trajectories, and expensive failures. Convert verified incidents into regression tests. This closes the loop between monitoring and engineering rather than treating dashboards as the finish line.
Trace the decision chain, not only the request
A useful trace links user intent, retrieved evidence, model invocation, proposed plan, policy decision, tool execution, verification, human intervention, and final outcome. Preserve stable identifiers across asynchronous jobs and external services. Teams should be able to answer what the system believed, what it was allowed to do, what actually happened, and who changed the decision.
Capture structured attributes rather than relying on raw prompts. Useful fields include model and prompt version, tool schema version, retrieval source versions, token and latency measures, policy result, retry count, approval state, and outcome classification. Sensitive content should be redacted or referenced through controlled storage rather than copied indiscriminately into telemetry.
Design operational views around questions
Executives need outcome, cost, and risk trends. Product owners need completion, escalation, and user correction. Engineers need traces, dependency failures, and version comparisons. Reviewers need evidence and policy context. One dashboard rarely serves all four audiences; use a shared event model with views designed for their decisions.
Alerts should identify actionable conditions such as a tool error spike, rising review rate, missing provenance, cost per accepted outcome, or a regression isolated to one workflow. Alerting on token volume alone creates noise. Pair each alert with an owner, investigation path, and safe fallback.
Executive decision record
The decision is which telemetry is necessary to explain outcomes, operate safely, control cost, and improve behavior without collecting unnecessary sensitive content. Write that decision before selecting a model, vendor, framework, or implementation pattern. A written boundary keeps technical exploration connected to the operating outcome and makes it possible to explain why the organization advanced, revised, or stopped the work.
Approval should depend on end-to-end correlated traces, versioned attributes, outcome measures, redaction tests, actionable alerts, and incident reproduction. The evidence does not need to remove every uncertainty, but it should address the uncertainty capable of changing value, architecture, risk, or ownership. Record the baseline, assumptions, unresolved questions, and the person accepting the next stage.
Failure boundary and operating ownership
The central failure to guard against is collecting large prompt logs but lacking the structured policy, tool, state, and outcome events needed to answer what happened. Treat that condition as a testable scenario. Define how the system detects it, what users experience, which action is prevented or reversed, and what evidence reaches the person responsible for recovery.
Long-term accountability sits with the service team operating the agent, with platform standards and security oversight for telemetry handling. Supporting specialists can provide platforms, research, review, or delivery capacity, but they cannot substitute for an owner who controls policy and operating change. Name that owner before production and include the ownership path in release evidence and incident procedure.
A practical 90-day application plan
During the first 30 days, convert end-to-end correlated traces, versioned attributes, outcome measures, redaction tests, actionable alerts, and incident reproduction into a bounded evidence plan. Assign each artifact to a named contributor, identify the representative inputs required, and agree on the comparison baseline before implementation expands. The objective of this period is to expose the assumption most likely to invalidate the work while the cost of changing direction is still low.
During days 31 through 60, build or instrument the smallest complete workflow that can support the decision about which telemetry is necessary to explain outcomes, operate safely, control cost, and improve behavior without collecting unnecessary sensitive content. Include the real data and authorization path where feasible, record exceptions, and review difficult cases with the people who own the underlying process. Resist adding breadth until the team can explain the measured behavior of this narrow slice.
During days 61 through 90, test the boundary represented by collecting large prompt logs but lacking the structured policy, tool, state, and outcome events needed to answer what happened. Exercise degraded dependencies, ambiguous inputs, recovery, and handoff rather than demonstrating only successful cases. End the period with a written advance, revise, or stop decision that cites evidence, residual exposure, expected operating cost, and the next authority boundary.
The review should be accepted by the service team operating the agent, with platform standards and security oversight for telemetry handling. That group should confirm not only that the system can work, but that ownership, support capacity, monitoring, and change control are credible. If those conditions are absent, the responsible outcome is another bounded learning stage rather than an unsupported production commitment.
Practical checklist
- Assign one trace to each user-visible task.
- Instrument retrieval, model, policy, tool, and review steps.
- Set cardinality limits for high-volume dimensions.
- Redact or avoid sensitive content by default.
- Define retention and access for debugging evidence.
- Alert on outcome and policy failures, not token counts alone.
- Turn production incidents into regression cases.
Engagement scenario
A procurement agent becomes slow only for one supplier class. Traces show that a missing identifier causes repeated search-tool calls before escalation. The team fixes the validation step, adds a loop-limit alert, and converts the run into a regression test.
Continue reading
- [Enterprise agent architecture](/enterprise-ai-agent-architecture)
- [LLM evaluation framework](/llm-evaluation-framework-production)
- [AI platform observability](/ai-platform-observability-opentelemetry)
Sources and further reading
- [OpenTelemetry: GenAI observability](https://opentelemetry.io/blog/2026/genai-observability/)
- [OpenTelemetry observability primer](https://opentelemetry.io/docs/concepts/observability-primer/)