What are teams using for AI-agent observability in production—and what is still broken?

The operating picture: what to observe

Instrumenting every prompt without outcomes creates an expensive transcript archive. Start with the decisions and artifacts that let an on-call engineer, product manager, and evaluator answer three different questions:

Minimum telemetry for every run

Use an application-level run_id in addition to the distributed trace_id. A trace can cover a request; a durable run can survive queueing, retries, handoffs, and asynchronous work. Propagate both through message headers, jobs, tool calls, and feedback events.

OpenTelemetry’s general semantic conventions exist specifically to standardize names for operations and data across code, libraries, and platforms. Use those names where they are stable; use a documented, namespaced application schema for what the standard does not yet model. OTel semantic conventions

Trace the state machine, not just calls

An agent is often a stateful workflow, not a single LLM request. Emit a state-transition event or span whenever durable control changes, for example:

queued → planning → awaiting_tool → running_tool → synthesizing
      ↘ waiting_for_approval → approved/rejected
      ↘ retrying → compensating → failed
                              ↘ completed

For each transition record the previous and next state, monotonically increasing state version, actor (agent, user, system, human), triggering event, and checkpoint/reference. This makes stuck work observable and lets an operator see whether an apparent success was followed by compensation or a later reversal. Do not put the entire mutable state object on a span.

Current OTel and GenAI conventions: use them carefully

As verified on 2026-08-25, the maintained GenAI conventions cover GenAI client operations, agents, workflows, tools, memory, retrieval, metrics, events, MCP, and provider-specific extensions. The dedicated repository explicitly includes spans, metrics, and events for GenAI clients, MCP, and providers. GenAI conventions repository

Use this hierarchy where your instrumentation supports it:

HTTP/server request or queue-consumer span
└─ invoke_agent <agent-name>                 [agent run]
   ├─ plan                                   [optional orchestration phase]
   ├─ generate_content / chat                [model call]
   ├─ execute_tool <tool-name>               [tool execution]
   │  └─ HTTP, DB, RPC, or MCP client spans  [dependency detail]
   ├─ retrieval / memory operation
   ├─ invoke_agent <subagent-name>           [handoff/subagent]
   └─ outcome-recorded                       [application event or span]

For a tool span, the developing convention recommends gen_ai.operation.name = execute_tool, a required low-cardinality tool name, and a tool-call ID when available; arguments and results are opt-in because they can be large or sensitive. Instrument direct application tool calls manually when automatic instrumentation cannot see them. OTel GenAI tool-span definition

For MCP, avoid duplicating an outer tool span and a second overlapping transport span when your instrumentation can correlate them. The MCP convention specifically recommends adding MCP attributes to the existing tool-execution span when duplicate instrumentation can be detected. OTel MCP span guidance

Content capture is a security setting, not a debugging default

Prompts, tool arguments, tool results, retrieved documents, and state may contain credentials, personal data, commercially sensitive data, or instructions from untrusted content. Treat full content as an opt-in restricted payload, not an always-on trace attribute. The official OpenAI Agents SDK, for example, warns that generation and function spans can store sensitive inputs and outputs, and provides a setting to disable capture. OpenAI Agents SDK tracing and sensitive data

Recommended tiers:

The Collector is a useful enforcement point, but it is not the first or only one. Configure code to avoid emitting raw content; enforce an allow-list and value redaction at the Collector; then use backend access controls, retention, audit logs, and deletion workflows. The OTel redaction processor can fail closed by deleting non-allowlisted attributes and masking blocked values, but its own documentation calls it one line of defence rather than the whole compliance program. Redaction processor · OTel security guidance

A production reference architecture

User / API / scheduled trigger
          │  run_id + trace context + privacy class
          ▼
Agent application and durable workflow
  ├─ state/checkpoint store ───────────────┐
  ├─ model providers                       │
  ├─ tools / MCP / databases / queues      │
  └─ feedback & outcome API                │
          │ OTel traces, metrics, logs     │ immutable outcome/evaluation events
          ▼                                ▼
Privacy gateway + OTel Collector ───► Trace backend / AI workspace
  ├─ allow-list, redaction, encryption       ├─ trace investigation
  ├─ route by data class / residency          ├─ prompt/version linkage
  ├─ tail-sample errors, slow, risky runs     └─ trace-linked scores
  └─ fan out to APM + low-cost archive
                                              ▼
                  Dataset registry → offline experiments → release gate
                  Production samples → evaluators/human review → alerts/runbooks
                                              ▼
                                   warehouse/dashboard for outcomes and cost

Design rules for this architecture

1. One correlation contract. Every component knows run_id, trace_id, workflow_id, release, prompt version, model, tool version, and privacy class. Use opaque IDs in telemetry; resolve identities only in an access-controlled system.
2. Two linked data planes. OTel handles high-fidelity execution telemetry. An outcome/evaluation store handles mutable or delayed business facts such as user correction, refund, human approval, and verified completion. Link them; do not force every fact into span attributes.
3. Raw content is referenced, not replicated. A payload_ref, digest, schema version, length, redaction status, and access classification often answer operational questions without copying data to every destination.
4. Version every behavior-changing input. At minimum: agent code/release, prompt/template, model/config, tool schema/version, retrieval index/corpus, policy/guardrail, evaluator/rubric, and pricing table.
5. Model side effects as transactions. Record side_effect_class (read, reversible_write, irreversible_write), idempotency-key reference, approval status, external reference, and compensation result. A tool returning HTTP 200 is not proof that a business action was correct.

Illustrative instrumentation pattern

This is deliberately framework-neutral pseudo-code. The important part is the contract, not the wrapper library.

with trace_span("invoke_agent support_agent") as run_span:
    run_span.attributes.update({
        "gen_ai.operation.name": "invoke_agent",
        "app.run.id": run_id,
        "app.workflow.version": workflow_version,
        "app.prompt.version": prompt_version,
        "app.privacy.class": privacy_class,
    })

    record_state_transition(run_id, "queued", "planning", state_version=8)
    plan = agent.plan(redacted_input)

    with trace_span("execute_tool customer_lookup") as tool_span:
        tool_span.attributes.update({
            "gen_ai.operation.name": "execute_tool",
            "gen_ai.tool.name": "customer_lookup",
            "app.tool.schema.version": "2026-08-01",
            "app.tool.side_effect_class": "read",
        })
        result = call_tool(validated_arguments, timeout_s=4)
        record_tool_result_class(tool_span, result)  # ok, timeout, denied, invalid, stale

    outcome = verify_or_mark_pending(result)
    record_outcome(run_id, outcome, evidence_ref=outcome.evidence_ref)

Do not record a generated “reasoning” field as if it were ground truth. A better decision record is factual and auditable: selected_tool, candidate tools, validated preconditions, policy/rule IDs, retrieved evidence references, current state version, and whether a human approved the step. This can explain the observable basis of a branch without exposing hidden reasoning or treating an after-the-fact explanation as causal evidence.

Measuring latency, tokens, and cost without fooling yourself

Track latency as a decomposition, not one number:

• end-to-end request/run time;
• queue and scheduler delay;
• planner/model time, including time-to-first-token (TTFT) for streamed responses;
• tool and external dependency time;
• retries, backoff, human-wait time, and compensation time;
• time from run completion to verified business outcome, where relevant.

Track provider-reported input, output, cached, and reasoning tokens when available, alongside the raw usage payload reference and the model/provider. The OpenAI Agents SDK’s current usage model, for example, records requests, input/output/total tokens, cached-token detail, and per-request usage snapshots; other providers differ, so normalize without erasing the original provider values. OpenAI Agents SDK usage tracking

For monetary cost, calculate a reproducible estimate using provider, model, usage fields, currency, price-card version/effective date, and non-model costs such as tool API charges, embeddings, retrieval, egress, queue/compute, and human-review time. Label it estimated_cost unless it reconciles to provider billing. Attribute shared context and retries consistently; otherwise dashboards will reward an agent that simply moves work into an uncharged dependency.

At high volume, keep cheap aggregate metrics at 100% and retain full traces intentionally: all errors, policy denials, consequential side effects, negative feedback, cost outliers, and latency outliers; a representative baseline sample for healthy traffic; and a privacy-approved debug sample. Tail sampling can select using the completed trace (for example, error, latency, or attribute-based policies), but it is stateful and operationally costly. OTel sampling guidance

Evaluations, experiments, and feedback: the missing half of observability

Use a closed improvement loop

Production trace / feedback / incident
        → reviewed failure mode
        → named dataset example + expected constraint
        → deterministic or rubric-based evaluator
        → offline experiment across prompt/model/tool/index variants
        → release gate and canary
        → production monitoring and human audit

This prevents the common failure where a team repeatedly inspects interesting traces but never turns the problem into a regression test.

Use three complementary evaluation types:

Run online evaluation on appropriately sampled production traces, but never turn a judge score into an autonomous high-impact decision without a separately validated policy and human governance. Online evaluators often lack a reference answer; they detect heuristics, anomalies, and degradation rather than establish truth. LangSmith’s documentation makes this distinction explicitly for production runs and threads. LangSmith evaluation concepts

User feedback should be attached to the exact trace or output span whenever possible. Record the signal type (thumbs down, edit, abandonment, escalation, refund, support ticket, explicit correction), time lag, optional reason category, and whether a reviewer confirmed it. A thumbs-down is a valuable lead, not a universal correctness label. Phoenix’s documentation shows this practical pattern: human annotations, user feedback tied to traces, and automated evaluations can be attached to the same execution record. Phoenix annotations and evaluations

Make experiments reproducible

For every experiment, store:

• dataset version and selection criteria, with data-leakage and privacy review;
• agent/code release; prompt/template and rendering policy; model and invocation configuration;
• tool implementations/schemas and mocked versus live dependency mode;
• retrieval corpus/index version and freshness point;
• evaluator code or judge prompt, rubric, model/version, threshold, and human-calibration result;
• random seed/temperature where meaningful, run timestamp, rate-limit policy, and pricing version.

Compare quality, safety, reliability, latency, and estimated cost together. A new model that raises a rubric score but doubles P95 latency or violates a tool rule is not automatically an improvement. Treat test results as evidence with confidence limits, especially for rare harmful modes.

Build versus buy

The table is a decision aid, not a vendor ranking. Product capability, hosting regions, pricing, and compatibility change quickly; verify the current plan, data residency, retention, and export terms during procurement.

Useful current references: LangSmith supports OTel-compatible tracing and can route to LangSmith, another OTel backend, or both. LangSmith OTel tracing Langfuse documents an OTel-based SDK, latest prompt/evaluation integration, and both Cloud and self-hosted deployment. Langfuse SDK overview · Langfuse evaluation model · Langfuse self-hosting Phoenix documents open-source AI observability with OTel/OpenInference support, tracing, evaluations, datasets, and experiments. Phoenix overview · Phoenix experiments

A practical selection rule

• Choose framework-native first if you are all-in on one framework, need immediate developer visibility, and accept the product’s operational model.
• Choose an OTel-native AI workspace if portability, self-hosting, or integrated prompt/eval workflows matter. Keep OTel at the application boundary anyway.
• Pair your existing APM with a focused AI evaluation/outcome workflow if service reliability and incident response are already solved there.
• Build custom only after writing the specific unsatisfied requirement and estimating the ongoing ownership cost. “We want a nicer trace viewer” is rarely enough.

One observed production anecdote in the source thread reported using LangSmith together with Honeycomb and wished the general observability layer understood evaluations and experiments; another reported Langfuse with custom client-facing outcome reporting. Treat these as examples of the common hybrid pattern, not market-share data. Observed thread

What remains poorly handled—even with good tooling

1. Semantic correctness and real-world outcomes. An agent can execute every span successfully, call the expected tool, and still give the wrong answer, alter the wrong record, or create downstream corrupt state. Outcome instrumentation and domain checks are application work.
2. Causally trustworthy “why.” Trace trees show sequence and inputs, not necessarily the model’s true decision process. Generated explanations and exposed reasoning should not be treated as evidence. Capture observable constraints, evidence, and branch triggers instead.
3. Delayed and missing labels. Users may never give feedback; a reversal may appear days later; the business may not expose a ground truth. Online judging helps prioritize review but does not remove this uncertainty.
4. Cross-agent and asynchronous context. Handoffs, queues, retries, background workers, long-lived conversations, and third-party tools frequently break trace context or confuse parentage. Test propagation with real failure/retry paths.
5. Tool semantics and side effects. HTTP success, a schema-valid response, and a business success are different states. Retry logic can duplicate writes unless idempotency and compensation are designed first.
6. Privacy versus diagnosability. The payload that makes a trace debuggable is often the one that increases exposure. Redaction can miss new formats; strict redaction can make an investigation inconclusive. Use controlled evidence access and build evaluation fixtures that do not need live sensitive data.
7. Schema churn and uneven instrumentation. Current GenAI agent/MCP conventions are developmental, auto-instrumentation misses custom tools and state transitions, and vendors map OTel attributes differently. Contract tests should check required spans and attributes after upgrades.
8. Cost attribution. Token counts are not total cost, provider usage may vary, and retries, embeddings, tool charges, and human review are easily omitted.
9. Rare, adaptive failures. Sampling and fixed datasets under-represent new attacks, unusual inputs, and long-tail user goals. Keep an incident-to-dataset process and periodically add adversarial, multilingual, and tool-failure cases.
10. Non-engineer comprehension. A narrative dashboard can summarize verified outcomes, top failures, costs, and actions, but it cannot responsibly invent causal explanations. Give PMs and clients an outcomes view; reserve raw traces for trained operators.

Implementation sequence

1. Define the service contract. List task types, side effects, success/reversal definitions, acceptable P95 latency, per-task cost budget, approval rules, and an owner for each metric.
2. Adopt correlation IDs and version tags. Add run_id, trace context propagation, release/prompt/model/tool/policy versions, tenant pseudonym, and privacy class at request entry.
3. Instrument the skeleton. Create root run spans plus child model, tool, retrieval, queue, database, and external HTTP/MCP spans. Add manual instrumentation for durable state transitions and custom tools.
4. Add the outcome API before the dashboard. Emit outcome_pending, outcome_verified, reversed, escalated, or a domain-specific terminal fact with evidence references. Make this idempotent and late-arriving-event safe.
5. Set payload policy. Make raw prompt/tool/result capture off by default in production. Implement allow-lists, redaction tests, encryption, RBAC, retention tiers, region routing, auditability, and a deletion process.
6. Deploy a Collector gateway. Receive OTLP centrally; authenticate and encrypt ingress; redact/filter before export; fan out to the chosen AI workspace, existing APM, and a low-cost archive if required. OTel documents Collector processors for modifying, filtering, and routing telemetry before export. Collector configuration · Transforming telemetry
7. Build a small, high-value regression set. Start from real, privacy-reviewed incidents: wrong tool selection, stale retrieval, timeout, malformed tool result, duplicate side effect, user correction, prompt-injection attempt, and policy rejection. Add deterministic checks first.
8. Run experiments and release gates. Compare candidates against the same dataset and record quality, policy violations, P95 latency, and cost. Canary only after offline evidence; automatically roll back only on clearly specified technical/policy signals.
9. Add production evaluators and feedback triage. Sample production runs; calibrate judges against humans; feed reviewed failures into the regression set. Do not silently train or change high-impact behavior from unreviewed feedback.
10. Operate it. Dashboard by service owner; create alerts, severity definitions, an incident runbook, and a monthly review of retained payloads, schema coverage, and the top unresolved failure modes.

Operational checklist

Before production

• Success, failure, reversal, and escalation are defined per task type.
• Every run receives a stable run_id, trace context, release, prompt, model, tool, and policy version.
• All externally consequential tools have validation, idempotency, timeout, retry, and compensation/approval semantics.
• State transitions and queue/handoff boundaries are instrumented, not inferred from log lines.
• Raw content capture is disabled by default; the allow-list, redaction, access, retention, and deletion controls have been tested with realistic data.
• The trace tree is tested for normal, timeout, retry, cancellation, approval, and compensation paths.
• A privacy-reviewed dataset includes known failures and negative cases.
• Release gates cover at least deterministic policy/tool checks, quality, P95 latency, and cost.

During operation

• Alert on tool/policy error rate, stuck/long state duration, queue lag, completion/reversal rate, negative feedback rate, evaluator drift, P95/P99 latency, and cost per verified outcome.
• Retain full traces for errors, policy denials, expensive/slow runs, consequential side effects, and reviewed negative feedback, subject to privacy policy; sample the rest intentionally.
• Page a human for consequential or regulated decisions; do not let observability or evaluator automation become an unreviewed decision-maker.
• Link every incident to a trace, outcome evidence, root-cause category, and one regression test or an explicit reason it cannot be tested.
• Reconcile estimated cost with billing regularly and revise the price-card version.

Monthly or after a significant change

• Review required-span coverage and broken context propagation after SDK/framework/model upgrades.
• Recalibrate evaluators on recent blinded human labels; check disagreement by language, task type, and cohort.
• Remove unneeded telemetry fields and expired restricted payloads.
• Re-test redaction with new prompt formats, tool schemas, attachments, and secrets patterns.
• Review state-duration baselines and alert thresholds after product changes.

Safety, privacy, and regulated-use boundary

Observability can support safety controls; it does not establish legal compliance or make a high-impact agent safe. If the agent processes health information, makes medical recommendations, influences credit, employment, insurance, housing, education, legal matters, children’s data, or performs financial transactions, involve the appropriate legal, privacy, security, domain, and human-oversight owners. Define jurisdiction-specific retention, data residency, consent, access, audit, and human-review requirements before recording payloads or acting automatically. Do not use a trace or an LLM evaluator as the sole evidence for a consequential decision.