Most teams instrument their agents the way they instrument an API: log the request, log the response, alert on errors. Then the agent starts failing in production in ways the logs cannot explain — right answer, wrong route; correct output, four redundant tool calls; a task that resolved but cost eleven times what it should have. The instrumentation is not wrong. It is measuring the wrong unit.
The unit of observability is the step, not the answer
An agent run is a tree, not a transaction. Every model call, tool invocation, retrieval and reasoning hop is a decision point that determines the next one. If you capture only the final response, you have captured the one artefact that tells you least about why it happened.
The working definition: each step becomes its own span, carrying inputs, outputs, latency, token counts, cost, and the decision that led to the next step. Spans assemble into a hierarchical trace covering the whole run. Once you have that, questions that were previously unanswerable become trivial — which tool is responsible for 60% of latency, how often the agent retries the same retrieval, whether failures cluster on a particular step or a particular input class.
Use OpenTelemetry, not a proprietary format
The GenAI semantic conventions in OpenTelemetry define a shared vocabulary for AI telemetry: a standard set of gen_ai.* span and metric attributes that any instrumentation library can emit and any backend can ingest. This matters more than it sounds.
OTEL is a CNCF standard with genuine vendor neutrality. Instrument once and ship traces to Grafana Tempo, Jaeger, Honeycomb or Datadog without touching instrumentation code. Given how quickly the agent tooling market is consolidating and re-forming, the ability to change backend without re-instrumenting is not a nice-to-have — it is the difference between a two-week migration and a two-quarter one.
The specialist layer sits on top rather than replacing it. LangSmith, Langfuse, Arize Phoenix, Braintrust and Confident AI lead the tracing-and-evaluation category, with Langfuse and Phoenix the common choices for open-source, OTEL-native setups. Pick one for the evaluation workflow; keep the transport standard.
What to put on a span
Minimum viable schema for an enterprise agent, per step:
| Attribute | Why it earns its place |
|---|---|
| Step type (model call / tool / retrieval / decision) | Lets you aggregate by class instead of by name |
| Model and version | Regressions are usually version boundaries |
| Input and output tokens, cost | Cost per resolved task is a step-level rollup, nothing else |
| Tool name and arguments | The argument distribution is where misuse shows up first |
| Latency, split queue vs compute | Distinguishes a slow model from a saturated one |
| Retry count and reason | Silent retries are the most common hidden cost |
| Agent identity and delegated scope | Ties the trace to your governance model |
| Outcome and confidence | Needed to compute resolution rate rather than completion rate |
The two that teams skip and later regret: retry reason, and delegated scope. Retries hide cost; scope is what makes the trace admissible as an audit record.
The metrics that actually change decisions
Dashboards fill up with token counts and p95 latency because those are easy. Neither drives a decision on their own. Four that do:
- Cost per resolved task. Not cost per call, not cost per conversation. Denominator is tasks that reached the intended outcome without human rescue. This is the number that makes a build-versus-buy or model-routing argument concrete — the same lens as reducing inference cost.
- Step efficiency. Steps taken versus the minimum plausible path. A rising ratio is the earliest signal of prompt or tool-description drift, usually visible weeks before quality metrics move.
- Human intervention rate, segmented by cause. Aggregate intervention rate is a vanity metric. Segmented — missing capability, low confidence, policy block, error — it is a roadmap.
- Tool error rate by tool. Agents route around broken tools by inventing worse paths, so a failing tool presents as degraded reasoning. Only per-tool telemetry separates the two.
Observability is not evaluation, and both are required
The distinction gets muddled because the vendors sell both. Evals are pre-deployment: a fixed dataset, a scored run, a gate before release. Observability is post-deployment: unbounded real inputs, no ground truth, and the job is to detect that something changed.
The connection between them is the loop most teams never close. Production traces that ended in intervention or failure are the highest-value eval cases you will ever get — they are, by definition, drawn from the real input distribution. A pipeline that promotes failed traces into the eval set is the single highest-return piece of engineering in an agent programme, and it is roughly a week of work.
Retention, privacy and the trap in full-payload tracing
Traces containing full inputs and outputs are the richest debugging asset you will build and a serious data-governance liability. Agent traces routinely contain customer PII, internal documents and credentials in tool arguments. Three practices keep this manageable:
- Tiered retention. Full payloads for days, structural metadata for months. Most debugging happens inside 72 hours; most trend analysis needs only the shape.
- Redaction at emission, not at query. If sensitive values reach the backend, they are in backups and you no longer control them.
- Classification-aware sampling. Sample heavily on low-sensitivity flows, retain fully on high-value ones. Uniform sampling gets both wrong — see classifying what may enter an LLM.
Where to start if you have nothing
Do not begin with a platform selection. Begin with OTEL instrumentation on one agent, spans on every step, and the four metrics above computed from those spans. That is days of work and it will immediately reveal something you did not know — in our experience it is usually a redundant retrieval loop or a tool that has been failing silently since a deploy nobody connected to it.
Platform choice gets much easier once you know what your traces look like. Choosing first means buying a workflow before you understand your workload, which is how organisations end up with an expensive dashboard nobody opens.
Frequently asked questions
What is agent observability?
Capturing the internal execution of an agent run — every model call, tool invocation, retrieval and decision — as structured spans assembled into a trace, so that behaviour in production can be explained rather than merely logged.
How is it different from evals?
Evals run before deployment against a fixed dataset with known correct answers, and act as a release gate. Observability runs in production against unbounded real inputs with no ground truth, and its job is to detect change and explain failure. Both are needed, and production failures should feed back into the eval set.
Do we need OpenTelemetry specifically?
You need a vendor-neutral transport, and OTEL is the one with GenAI semantic conventions and CNCF backing. Instrumenting to a proprietary SDK works until you change backend, at which point the cost lands all at once.
What is the single most useful metric?
Cost per resolved task. It combines quality, efficiency and spend into one number that survives contact with a finance conversation, and it can only be computed from step-level telemetry.