Updated: 2026-07-12

A poorly instrumented AI agent is a black box that spends money. Model calls are expensive, tool calls can be expensive too, and the decision flow is usually non-deterministic. Without instrumentation designed for this kind of system, when something fails or the bill comes in higher than expected, the team ends up reading loose logs and trying to reconstruct the sequence by hand. After a year and a half running agents in products with real users, this article covers what to instrument first, which standards have emerged, and which costly mistakes are avoided by getting the traces right from day one.

Key takeaways

  • Agents break the traditional observability mold in three ways: a single user input can trigger dozens of chained calls, each call carries an explicit economic cost in tokens, and the content of inputs and outputs is relevant for debugging.

  • OpenTelemetry consolidated during 2025 a set of semantic conventions for generative AI that define how to name spans, which attributes to use, and how to represent the relationship between the agent and the tools it invokes.

  • The five aggregated metrics worth instrumenting always: cost per conversation, end-to-end latency, successful completion rate, mean number of steps per conversation, and tool-use rate per step.

  • The most expensive failure in production is not having a way to answer «why did this conversation cost thirty euros».

  • Recommended minimum path: OpenTelemetry in the model SDK, a Langfuse-type backend, five basic business metrics on a visible dashboard, and a simple automatic evaluation over a sample of traffic.

Why classical systems aren’t enough

Traditional observability was built around synchronous HTTP services: a request comes in, calls to databases and other services happen, and a response goes out. Distributed traces capture that call tree, metrics count requests per second and latency percentiles, and logs give context. With that toolkit, a well-practiced team can answer most operational questions.

Agents break that mold in three ways:

  • Dozens of chained calls: a single user input can trigger dozens of chained model calls, with branches and loops whose structure is only known after execution.

  • Explicit economic cost: every call carries an input and output token cost that matters as much as, or more than, latency.

  • Content relevant for debugging: unlike a normal API JSON payload, the content of inputs and outputs is necessary to understand why the agent made one decision over another.

First layer: one trace per run

The first thing to have is a trace per agent run, with each model call and each tool call as a nested span. OpenTelemetry[1] consolidated during 2025 a set of semantic conventions for generative AI[2] that define how to name spans, which attributes to use, and how to represent the relationship between the agent and the tools it invokes. All the major LLM SDKs (OpenAI, Anthropic, Google, Azure) already ship automatic instrumentation that emits these spans with minimal code changes.

What to capture on each model-call span:

  • Model name and sampling parameters (temperature, token cap).

  • Input and output tokens counted.

  • Estimated cost in the provider’s currency.

  • Time to first token if streaming, and total time.

  • Input messages and output text or function calls.

This last point is delicate, because that content can include personal data, and the configuration must allow redacting or hashing it according to the organization’s policy.

For each tool call, the span should capture the tool name, the arguments, the result or error, and the time spent. OpenTelemetry context must propagate down to the tools that call external APIs, so the full tree stays visible.

Second layer: aggregated metrics

Loose traces don’t give you the big picture. You need aggregated metrics that let you look at the system’s behavior as a whole. The five worth instrumenting always are:

  • Cost per conversation in the provider’s currency.

  • End-to-end latency as seen by the user.

  • Successful completion rate versus abandonment or error.

  • Mean number of steps per conversation.

  • Tool-use rate per step.

With those five you can answer the usual operational questions without diving into individual traces: whether average cost suddenly spiked, whether a new model version worsens the completion rate, or whether a new tool is causing problems or being overused.

From there come more domain-specific metrics. If the agent has an expected happy path (a completed booking, a resolved query), it’s worth instrumenting the success rate on that path. If there are per-user budgets, it’s worth alerting when a conversation gets close to the limit.

Third layer: production evaluations

Classic observability stops there, but agents need one more layer: evaluations that run over real conversations, or samples of them, to measure quality. Knowing the conversation ended isn’t enough; you need to know whether it ended well. The techniques in use vary: manual annotation of samples, judgments by a model (LLM-as-judge) against defined criteria, and detection of specific patterns such as unnecessary refusals or detectable hallucinations.

What works in practice is a pyramid: a small fraction of conversations evaluated by humans, a larger fraction evaluated by a judge model, and the rest covered by cheap heuristic metrics. The three levels are periodically calibrated against each other to make sure the automatic judge doesn’t drift from the human baseline. This complements what we describe in testing with AI: the determinism problem: production evaluations are the observability layer that offline tests can’t replace.

The most common failure pattern

The most expensive failure that shows up in teams running agents in production is not having a way to answer the question «why did this conversation cost thirty euros». The conversation happened, the cost is on the bill, but the logs don’t contain enough detail to say whether it was an agent loop, a user prompt that filled the context window, a misconfigured tool, or the wrong model choice.

Without that traceability the team can’t prevent it from happening again, and the monthly LLM bill turns into a black box that keeps growing without explanation. It’s the same blind spot we describe in AI agent governance in the enterprise: without metrics or traces there is no operational guardrail possible, however well the policy is written.

The cure is to instrument from day one, even if it feels like overhead. Agents start small and grow fast; wiring up traces once you already have thousands of daily conversations is far more expensive than doing it at the start.

A minimum path

For a team starting today with an agent in production, the recommended minimum path is clear:

  • Turn on OpenTelemetry instrumentation in the model SDK being used, with the semantic conventions for generative AI.

  • Send those traces to a backend that understands conversations: Langfuse[3] or similar work well, or a Grafana Tempo with hand-built dashboards if you prefer self-hosted.

  • Define five basic business metrics and put them on a visible dashboard.

  • Set up a simple automatic evaluation, even if it’s just a judge model with three criteria, over a sample of traffic.

from opentelemetry import trace
from opentelemetry.instrumentation.openai_v2 import OpenAIInstrumentor
import openai

OpenAIInstrumentor().instrument()
tracer = trace.get_tracer("agent.bookings")

with tracer.start_as_current_span("conversation", attributes={"user.id": uid}) as span:
    response = openai.chat.completions.create(
        model="gpt-4o-mini",
        messages=messages,
        tools=tools,
    )
    span.set_attribute("agent.steps", len(response.choices[0].message.tool_calls or []))

That quartet covers eighty percent of the value. Finer layers get added later as the system grows: traces propagated to internal tools, per-user budgets, comparative evaluations across model versions, specific alerts.

My take

Agent observability moved in 2025 from being an uncomfortable gap to having acceptable answers. OpenTelemetry’s semantic conventions for generative AI, the maturing of platforms like Langfuse and Phoenix[4], and the addition of automatic instrumentation in the big providers’ SDKs mean the cost of entry is now affordable even for small teams. There is no excuse for running agents blind.

What’s still missing is full standardization for representing intermediate agent states, planning branches, and persistent memory. The ecosystem is moving fast there, and the conventions will keep changing over the next eighteen months. The prudent move for a team is to adopt the current conventions while assuming there will be migrations; the alternative, building something proprietary from scratch, almost never ages well.

Conclusion

Instrument early, instrument with open conventions, and revisit when more consolidated versions appear — that’s the policy that has worked best. Observability is not an add-on built when the agent is already in production; it is part of the design from day one.

This article is also available in Spanish: Observabilidad de agentes de IA: qué instrumentar primero.

Sources

  1. OpenTelemetry
  2. semantic conventions for generative AI
  3. Langfuse
  4. Phoenix