AI Agent Observability: Traces, Evals and Costs

Last updated: July 14, 2026 · By Ignacy Kwiecien, founder & editor-in-chief, DecodeTheFuture.org

What is AI agent observability?

AI agent observability is the instrumentation and operating practice used to understand an agentic application from the outside. It covers telemetry, trace structure, quality signals, privacy controls, alerting and the workflow for turning a failed run into a verified fix.

A conventional request often has a short path: HTTP request, application code, database query and response. An agent can add model selection, context assembly, retrieval, planning, tool calls, retries, handoffs, approvals and a final answer. A single “request succeeded” metric hides too much. The HTTP request may have returned 200 while the agent called the wrong tool, leaked sensitive context, exceeded its budget or produced an answer that failed the business task.

Observability therefore has to preserve the shape of the run. A useful record answers five questions:

1. What happened? Which workflow, agent, model, prompt version, tools and data sources were involved?
2. Where did time and money go? Which model call, retrieval step or tool dominated latency and cost?
3. Was the result useful? Did it satisfy a deterministic contract, a rubric or a human reviewer?
4. Was the run safe? Did it expose private data, attempt a disallowed action or bypass an approval boundary?
5. Can we reproduce the diagnosis? Can an engineer find the same trace, prompt version, tool result and evaluation after deployment?

Why agent telemetry needs a trace tree

A trace is the end-to-end record for one logical task. Spans are the timed child operations inside it. The exact names vary by framework, but the hierarchy should make the execution legible. For the broader production stack, see AI Architecture for Production; for trust boundaries around tools and approvals, see AI Agent Security 2026.

The most valuable trace is not necessarily the most verbose trace. Capturing every prompt, retrieved document and tool payload can create privacy, retention and cost problems. The design goal is diagnostic sufficiency: enough structured evidence to explain a decision, with redaction and sampling rules that make the telemetry safe to store.

The minimum event model

Before choosing a platform, define a small internal vocabulary. Vendor dashboards can map their fields to it, while OpenTelemetry can carry the common infrastructure context. The OpenTelemetry GenAI conventions are still evolving, so record the convention version and keep application-owned fields namespaced rather than pretending every field is stable.

Instrument the workflow before the model

A common mistake is to add a model callback and call the system observable. That captures token counts but not the business operation around the model. Start at the workflow boundary, then instrument each meaningful transition.

1. Define the trace boundary. One customer request, scheduled job or batch item should have one stable trace. Use a group or conversation identifier only when several traces belong to one user journey.
2. Propagate context. Pass the trace context through queues, async tasks, tool workers and HTTP calls. A tool executed in another service should remain a child or linked span, not an unrelated log line.
3. Separate planned from executed actions. Record the agent’s proposed tool call and the actual tool result as different events. This helps identify schema errors, policy blocks and external failures.
4. Version prompts and policies. A prompt hash is not enough when the prompt is assembled from retrieved instructions. Store a stable prompt or policy version and the identifiers of the components that were selected.
5. Capture errors structurally. Record timeout, rate limit, validation failure, refusal, policy block and business rejection as distinct outcomes. “Exception” is too broad for an agent runbook.

OpenAI’s Agents SDK is an example of a framework that creates traces and spans for agent runs, generations, function tools, guardrails and handoffs. It also exposes a setting that disables sensitive data capture. The framework-specific surface is useful, but the operating principle is portable: the trace should mirror the execution graph.

from agents import Agent, Runner, RunConfig

agent = Agent(
    name="support_triage",
    instructions="Classify the request and use approved tools only.",
)

result = await Runner.run(
    agent,
    input="Classify this support request",
    run_config=RunConfig(
        workflow_name="support-triage",
        group_id="conversation-123",
        trace_include_sensitive_data=False,
        trace_metadata={"prompt_version": "triage-2026-07-14"},
    ),
)
print(result.final_output)

Do not copy this example into production without checking the SDK version and your own data policy. A flag that prevents sensitive payload capture is helpful, but it does not decide which identifiers, tool outputs or application logs are safe. That remains an architectural responsibility.

OpenTelemetry, native SDKs and the portability decision

There are three practical instrumentation strategies:

OpenTelemetry’s GenAI work gives teams a shared direction for provider, model, token, operation and evaluation signals, but the specification includes development-status areas. Treat it as a contract to monitor, not a reason to delete your own compatibility layer. Keep an internal event schema and map it to the exporters you use.

LangSmith documents tracing, monitoring, alerts, automations and online evaluations. Phoenix is built on OpenTelemetry and OpenInference and combines tracing with evaluations, datasets and experiments. Langfuse, covered in the companion roundup, is another option for teams that want open-source or self-hosted control. These tools can be useful destinations; none removes the need to define what a successful task means.

What to measure: reliability, quality, cost and safety

Agent observability becomes operationally useful when every metric is tied to a decision. A dashboard with dozens of time series can still fail to answer whether the product is improving.

Agent-specific metrics that ordinary APM misses

• Steps per successful task: an increasing step count can signal prompt drift, weak routing or a loop.
• Tool selection accuracy: compare the selected tool with a labelled or deterministic expected capability.
• Replan and retry rate: distinguish a useful recovery from repeated attempts that only increase spend.
• Handoff rate: measure how often a task moves between agents and whether the handoff improves completion.
• Approval friction: count approvals requested, approved, rejected and timed out; a low approval rate can be a product or policy problem.
• Cost per successful task: total tokens divided by successful outcomes is more informative than average tokens per request.

Traces show behaviour; evals show quality

A trace can prove that the agent retrieved three documents and called a CRM tool. It cannot prove that the answer was correct or that the right customer record was updated. Evaluation adds a repeatable quality signal to the trace.

Use several evaluator types:

• Deterministic checks: JSON schema validation, required citations, permission checks, exact fields, status transitions and numerical invariants.
• Model-based graders: rubric-scored correctness, relevance, groundedness, style or tool-use quality. Treat judge output as a signal, not an objective truth.
• Human review: a sampled queue for ambiguous, high-impact or safety-sensitive tasks.
• Outcome labels: the business result, such as accepted resolution, successful deployment, resolved ticket or corrected transaction.

Arize Phoenix documents both code-based and LLM-based evaluators and supports evaluation on traces, datasets and experiments. This is the right mental model: evaluations should be able to inspect the same evidence that an engineer uses during debugging.

Build an eval loop from real traces

1. Sample runs deliberately. Include successes, failures, long-tail latency, tool errors, guardrail blocks and high-value customer segments. Random samples alone underrepresent rare failures.
2. Redact before dataset creation. Remove secrets and personal data, or replace them with stable placeholders that preserve the test structure.
3. Freeze a baseline. Keep a versioned dataset, evaluator version, model identifier and prompt version. A score without these dimensions is not comparable.
4. Run offline regression tests. Test the candidate prompt, model or tool schema against the same cases before rollout.
5. Use shadow or canary traffic. Compare production-like traces without giving the candidate system authority to perform irreversible actions.
6. Close the loop. Turn confirmed failures into a regression case. Do not rely on a one-off prompt tweak that cannot be tested again.

Cost and latency budgets for agent loops

Agents turn small inefficiencies into compound spend. If a task takes several model calls, retries and tool invocations, the average cost per request can conceal a costly tail. Track both total cost and cost per successful task.

A simple internal budget can be expressed as:

Set limits in code, not only in the prompt: maximum model turns, maximum tool calls, maximum wall-clock duration, maximum estimated spend and a clear fallback. When a limit is reached, emit a structured outcome such as budget_exceeded rather than a generic timeout.

Latency needs the same treatment. A p95 end-to-end target can be decomposed into model, retrieval, tool and queue budgets. The decomposition helps you decide whether to cache, parallelize retrieval, choose a smaller model or remove an unnecessary agent step.

Privacy and security are part of observability

Agent traces can contain the most sensitive data in a system: user prompts, retrieved documents, account identifiers, tool arguments and model outputs. More telemetry is not automatically better telemetry.

• Classify trace fields before enabling capture. Treat prompts, completions and tool payloads as potentially sensitive by default.
• Prefer hashes, IDs and references when the raw payload is not necessary for diagnosis.
• Redact secrets at the instrumentation boundary, not only in a dashboard view.
• Separate debug retention from long-term aggregate metrics.
• Restrict access to traces and log every export or sharing action.
• Test that a blocked tool call and a prompt-injection attempt do not leave sensitive content in an unintended sink.

Failure budgets and an agent runbook

Traditional SLOs often start with availability. For agents, an operational contract should include quality and safety. A service that is available but produces wrong tool actions is not healthy.

A useful incident sequence is alert → trace → span → evidence → regression test → guarded rollout. The alert identifies a changed signal. The trace identifies the affected execution. The span narrows the component. Evidence identifies the failure mechanism. The regression test prevents recurrence. The guarded rollout verifies the fix without giving a new agent unrestricted authority.

Reference architecture for production

A sensible first version has five layers: application instrumentation, an OpenTelemetry collector or native exporter, a trace and metrics backend, an evaluation pipeline, and an operational control plane. The quality and safety layer should read from traces but should not be allowed to rewrite them silently.

Implementation checklist

Before calling an agent observable, check each item:

1. Every logical task has a stable trace ID and workflow name.
2. Model, retrieval, tool, handoff, guardrail and approval operations appear as separate spans or events.
3. Prompt, policy, tool-schema and model versions are queryable.
4. Tokens, latency, retries, errors and estimated cost are recorded per task.
5. At least one deterministic evaluator and one human or model-based quality signal exist.
6. Representative failed runs can be promoted into a versioned regression set.
7. Trace retention, redaction and access controls are documented.
8. Budgets stop or degrade the agent before it can loop indefinitely.
9. Alerts link to an evidence-bearing trace, not only an aggregate number.
10. A model or prompt rollout has a canary, rollback and post-deployment comparison plan.

What to build first

If the system is currently invisible, do not start with an elaborate platform migration. Instrument one critical workflow end to end. Capture the trace, model spans, tool calls, cost, latency, outcome and a small redacted sample of inputs. Add one deterministic check and one human review queue. After that baseline exists, decide whether native tracing, OpenTelemetry, a self-hosted platform or an enterprise APM destination is the best operational fit.

The most important design decision is not which vendor has the most features. It is whether the team can connect a user-visible failure to an execution step, a quality signal and a code or policy change. That is the difference between an agent dashboard and an observability system.