AI Agent Observability: OpenTelemetry, Traces, Metrics, and Production Monitoring

An AI agent can return the correct answer and still be a production failure. It may call a restricted tool, repeat the same search eight times, use stale context, or spend more on inference than the task is worth. Conventional application monitoring can report a healthy HTTP response while missing those problems entirely.

AI agent observability is the practice of capturing and correlating the observable execution of an agent - model requests, tool calls, retrievals, state changes, handoffs, policy decisions, and final outcomes - so teams can diagnose failures, measure reliability, control cost, and supply evidence for evaluation and governance. It is not a claim that operators can read a model’s private internal reasoning. It is an engineering view of actions and results that the application can actually observe.

Quick answer: Trace the complete task, not only the final LLM call. Give every run an end-to-end trace ID; record structured model, tool, retrieval, and control spans; keep sensitive content out by default; and connect traces to outcome evaluations and business metrics.

Why normal LLM monitoring is not enough

A simple chatbot might require one model call. An agent may initiate a model call, retrieve documents, invoke an MCP tool, ask a specialist agent to investigate, wait for approval, and perform a transaction. Measuring only model latency and token count does not reveal whether the correct action occurred.

The unit of analysis should be a run, defined as a bounded attempt to complete a business task. A run may span several models, APIs, agents, and infrastructure services. For more on grading the resulting behavior, see AI agent testing and evaluation.

Reference architecture: one task, one correlated trace

USER / APPLICATION REQUEST
          |
          v
   Agent workflow span (run ID, trace ID)
          |
    +-----+-----------------------------+
    |                                   |
    v                                   v
Model call span                   Retrieval span
    |                                   |
    v                                   v
Tool execution span               Evidence metadata
    |
    +------> Approval / policy event
    |
    +------> Remote agent handoff span
    |
    v
Business-state verification
    |
    v
Outcome / evaluation result
    |
    +------> Metrics and alerts
    +------> Trace explorer
    +------> Evaluation dataset
    +------> Governance evidence

A trace is a tree of operations called spans. Each span records timing, status, identifiers, and selected attributes. Logs describe discrete events; metrics aggregate measurements across runs; traces connect the events into a causal timeline. You need all three, with consistent identifiers.

The practical span taxonomy

The OpenTelemetry Generative AI semantic conventions define agent and framework operations including invoke_agent, invoke_workflow, and execute_tool; inference spans cover model calls. As of October 2026, this GenAI convention set is marked Development, so instrumentations should pin and test their supported version rather than assuming every attribute name is final.

A pragmatic enterprise trace includes:

Memory and context retrieval require the same provenance and access checks described in the AI agent memory architecture guide. Do not record confidential payloads simply because the SDK makes it easy. For many use cases, a sanitized tool identifier and result status are sufficient; sensitive argument values can remain in an access-controlled application record.

Trace identifiers and propagation across services

Generate a unique trace_id for the distributed execution and a separate run_id or business_task_id for the domain workflow. A trace may be shorter than a business task if the workflow pauses for hours, so do not make the two identifiers interchangeable. Record the agent version and the release or prompt configuration with each run.

Propagate trace context through HTTP and RPC boundaries. The W3C Trace Context recommendation defines the traceparent header that lets participating services carry a common distributed-tracing context. For queue-based workflows and delayed agent handoffs, use documented context propagation or span links, together with the stable business task identifier.

In an MCP or A2A architecture, preserve correlation from the orchestrating agent into server/tool execution and back to the calling task. Preserve identity and authorization separately: a trace ID is not a permission token and must never be used as proof that an action was authorized.

What to capture on every model call

Each inference span should identify the requested and actual model when known, provider, duration, outcome, error class, token usage, and whether the result was streamed or retried. OpenTelemetry’s GenAI span conventions include fields such as gen_ai.usage.input_tokens and gen_ai.usage.output_tokens.

Record the relevant prompt version, retrieval configuration, model-routing policy, and cache decision as application metadata. Those configuration IDs explain why two runs using the same input behaved differently. Avoid high-cardinality unbounded labels such as full prompts in metrics; store detailed trace metadata only where needed.

For privacy, separate three classes of content:

1. Default telemetry: IDs, timing, status, counts, versions, and error categories.
2. Controlled diagnostic content: limited, redacted samples of prompts, tool parameters, retrieved snippets, and outputs.
3. Restricted business evidence: original records maintained in the appropriate source system under its access and retention policies.

The OpenAI Agents SDK tracing documentation demonstrates why this choice matters: tracing can capture model and tool inputs/outputs, and it supports controls for including sensitive data and custom tracing processors. Review the defaults of each framework you deploy.

Instrument a basic agent run

The following simplified Python snippet illustrates how application spans can be added around agent and tool operations. It does not invoke an LLM or configure a collector; actual production instrumentation should also include the applicable OpenTelemetry GenAI conventions and exporter settings.

from opentelemetry import trace

tracer = trace.get_tracer("enterprise.agent", "1.0.0")


def run_supplier_check(agent_version: str, task_id: str):
    with tracer.start_as_current_span("agent.supplier_check") as span:
        span.set_attribute("app.agent.name", "supplier-risk")
        span.set_attribute("app.agent.version", agent_version)
        span.set_attribute("app.task.id", task_id)
        with tracer.start_as_current_span("agent.tool.execute") as tool:
            tool.set_attribute("gen_ai.operation.name", "execute_tool")
            tool.set_attribute("gen_ai.tool.name", "lookup_supplier")
            # Call the authorized tool; capture metadata, not secrets.
            result_status = "success"
            tool.set_attribute("app.tool.result_status", result_status)
        span.set_attribute("app.task.outcome", "completed")

In the real workflow, the tool should enforce authorization independently and emit a verified result. The parent run span should record the final outcome only after the environment has been checked. See AI agent tool and function integration for the separate tool-boundary design.

Measure outcomes, operations, safety, and unit economics

An observability dashboard should not be a wall of token charts. Organize it into four questions: Did the task succeed? Did the system behave correctly? Was it safe? Was the cost justified?

A particularly useful measure is:

Cost per successful task
  = Total execution + retrieval + tool cost for the cohort
    / Number of verified successful tasks in that cohort

The denominator must use independently verified successes, not the number of agent messages saying “Done.” Segment these measures by task category, release, tenant tier, model family, and risk level. Do not put user identifiers into low-cardinality aggregate metric labels.

Model tokens are not the complete cost

An agent run may incur model inference, embeddings, vector search, external data fees, tool execution, approval labor, and retry overhead. Track the major components with the same run identifier so finance teams can analyze cost by product and workflow. Pricing should be versioned with an effective date rather than inferred from today’s provider rate for a historical run.

Diagnose a production failure from the trace

Suppose a claims agent takes 48 seconds to answer a question that normally takes six seconds. The trace shows three retrieval attempts, two calls to the same policy tool, one downstream timeout, and one fallback model call.

The incident process is straightforward:

1. Open the affected trace and identify its slowest or failing spans.
2. Inspect dependency errors and retry/fallback events without exposing raw customer content unnecessarily.
3. Compare the trace with successful runs of the same task type and version.
4. Determine whether the root cause was retrieval, tool latency, orchestration, model routing, or policy.
5. Create a regression case, fix the responsible component, and verify the outcome in a replayable test environment.

A trace alone explains what happened. An evaluator determines whether the resulting behavior met the task’s quality and policy criteria. This is why observability and LLM-as-a-Judge evaluation should be linked but not treated as the same product.

Trace-based evaluation without confusing the two disciplines

Attach evaluation results to trace IDs or a durable run ID. Examples include verified task completion, evidence-grounding scores, tool-selection correctness, and an action-policy check. Store each evaluator’s version, dataset, thresholds, and decision time.

For objective outcomes, use code and system-state checks. For semantic criteria, use calibrated model-based or human reviewers. Do not treat a polished final answer as proof that an external action succeeded. The companion AI agent evaluation guide owns rubric design, golden datasets, multi-trial reliability, and release gates.

A healthy workflow looks like:

TRACES --> FAILURES --> LABELS --> EVAL CASES
   ^                                    |
   |                                    v
PRODUCTION <-- CANARY <-- RELEASE GATE / TESTS

Security, privacy, and retention of agent telemetry

Observability creates a new sensitive-data surface. Prompt text, retrieved passages, tool parameters, customer identifiers, and generated outputs may expose private or proprietary information even when the original application is secure.

Use a metadata-first collection policy. Control diagnostic-content sampling, redact or tokenize sensitive fields before export, segregate tenants, encrypt data in transit and at rest, enforce role-based access, and define retention and deletion schedules. Do not put API keys, session tokens, or full customer records in span attributes. Guard against malicious text in retrieved content becoming executable commands in a log viewer or triage tool.

Security-relevant events such as attempted prohibited tool calls, approval overrides, credential failures, and policy denials should be retained under the organization’s security and audit policy, with a controlled process for restricted access. Review the adjacent AI agent security and agent governance guides for control design.

Sampling without hiding the important failures

Keeping every verbose trace forever is rarely necessary. A sensible policy is to collect basic metrics and incident counts broadly, sample successful detailed traces, and retain relevant error, policy-denial, approval, and high-risk event metadata at higher rates according to risk and retention policy. When tail-based sampling is available, keep slow or failed traces more frequently than ordinary successful ones.

Sampling can bias measured distributions. Compute task success rates and latency metrics from sufficiently representative counters or sampled data with an explicit methodology, not from an error-enriched trace sample as though it were unbiased traffic.

Observability for multi-agent, MCP, and human approvals

Cross-agent workflows are particularly difficult to debug because one parent task may include multiple agent versions and separately operated services. Capture a handoff record that identifies the source agent, destination agent, scope of delegated task, correlation ID, start/end, and result. A handoff is not automatically successful merely because the message was delivered.

For tool calls, record MCP server identity and tool name where available; keep tool authorization under the tool service rather than trusting a tracing layer. For approvals, record whether a decision was required, requested, granted, denied, expired, or bypassed through a documented emergency path. These events are both operational signals and audit evidence.

Use multi-agent orchestration patterns for delegation design and agent identity and authorization for the separate trust model.

Detect loops, drift, and runaway cost early

Useful alerts correspond to actionable failure modes, not arbitrary dashboards:

• Loop risk: repeated identical tool calls or step-budget exhaustion within one run.
• Retrieval degradation: rising empty results or stale-source hits for an indexed corpus.
• Model drift: a statistically meaningful change in performance within a stable task slice after a model or prompt change.
• Policy anomaly: abnormal increases in denied write operations or missing approval events.
• Cost anomaly: rising tokens or cost per successful task, not simply higher total traffic.
• Dependency incident: tool-specific P95 latency and error spikes correlated with task failures.

Each alert should have a runbook, named owner, relevant dashboard, severity, and safe rollback or disablement path. Link the incidents back to agent reliability engineering for retries, idempotency, circuit breakers, and recovery design.

A practical rollout plan for enterprise teams

Phase 1 - Define the run contract. Agree on task ID, trace context, agent/prompt/model versions, outcome status, and minimal telemetry. Identify sensitive content classes and retention boundaries first.

Phase 2 - Instrument the workflow. Add spans for model calls, tool executions, retrieval, handoffs, approvals, and verified outcomes. Ensure correlation survives HTTP, queues, and remote agents. Start with one representative agent.

Phase 3 - Add quality and business telemetry. Join traces to outcome verification, quality scores, cost, latency, and support incidents. Define SLOs by task risk rather than one global threshold.

Phase 4 - Operationalize. Add alerting, privacy-safe sampling, runbooks, regression-test generation, canary comparisons, and rollback decisions. Test that the observability pipeline itself cannot leak confidential data.

Phase 5 - Improve continuously. Review failing task slices, audit control coverage, and measure whether fewer incidents and lower cost per success justify instrumentation overhead.

Where KNOBS and KONTROLS fit

DataKnobs KNOBS connects telemetry, behavioral evaluation, and runtime optimization. Agent traces help teams identify high-impact variables such as routing, retrieval depth, memory scope, tool budgets, autonomy, and retry policies. KNOBS can then support evaluation and controlled experiments to determine which configurations improve outcomes rather than simply generating more logs.

KONTROLS has a complementary responsibility: enforce the permissions, policy checks, approvals, and evidence requirements that the trace must record. Observability is evidence of control operation; it is not a replacement for control enforcement.

Enterprise next step: Explore KNOBS for agent observability and optimization. Connect trace-level diagnostics with evaluations, cost and latency signals, and approved control changes across enterprise AI workflows.

Frequently Asked Questions

What is AI agent observability?

AI agent observability means recording and correlating an agent’s execution across model calls, retrieval, tools, handoffs, policy decisions, and verified task outcomes. It helps teams diagnose reliability, safety, cost, and workflow behavior.

How is agent observability different from LLM monitoring?

LLM monitoring focuses on model requests, tokens, latency, and response errors. Agent observability covers the entire multi-step task and can show whether tool use, delegation, approvals, and business-state changes succeeded.

Does OpenTelemetry support AI agent tracing?

Yes. OpenTelemetry has Generative AI semantic conventions for agent, workflow, inference, and tool operations. As of October 2026, the GenAI-specific convention set is still labeled Development, so production deployments should pin and validate their instrumentation versions.

Should an agent trace include prompts and tool arguments?

Not by default. Record metadata such as model, tool, duration, status, versions, and token usage broadly. Capture sensitive content only when there is a documented diagnostic purpose, appropriate consent or legal basis, redaction, access control, and retention policy.

What metrics matter most for production agents?

Verified task success, P95 completion time, tool failures, policy violations, retrieval quality, retries or loops, and cost per successful task are useful starting measures. Segment results by task, release, risk, and model instead of relying on one average.

Can observability prove that an agent made the right decision?

Not on its own. A trace shows observable activity and evidence. Deterministic checks, calibrated evaluators, or humans must establish whether the result and behavior met business and policy requirements.

Conclusion

Production AI agents need observability at the workflow level. Capture the complete execution, propagate identifiers across model and tool boundaries, keep private content protected, verify the real-world outcome, and use traces to feed evaluation and release decisions. The useful end state is not a larger logging bill: it is faster diagnosis, fewer silent failures, safer actions, and lower cost per successful task.

Sources

• OpenTelemetry: Semantic Conventions for GenAI Agent and Framework Spans
• OpenTelemetry: Semantic Conventions for GenAI Inference Spans
• OpenAI Agents SDK: Tracing
• OpenAI API: Agent Tracing
• W3C: Trace Context