If you cannot replay it, you cannot ship it.

The most common mistake in agent observability is treating the chat log as the observability layer. A transcript captures the conversation between the user and the model. It does not capture what the model tried internally: which tool it called first, what arguments it passed, what came back, whether the first attempt failed validation and got retried, or what other tool it considered and rejected.

Most production bugs live in exactly that gap. The model gave a wrong answer not because its language generation was bad, but because a tool call returned stale data, or a retry silently used a fallback value, or the context window truncated a critical instruction before the final generation step. None of that shows up in a transcript. It only shows up in a trace.

Treat every agent run as a distributed trace, the same discipline you'd apply to a microservices request. Each run needs:

• A unique trace ID generated at the start of the run and threaded through every subsequent call, log line, and error.
• The full prompt sent to the model at each step, including system instructions, not a summary of it.
• Every tool call, with its name, arguments, raw result, and whether the result passed schema validation.
• Retries and fallbacks, explicitly labeled as such, not silently merged into the trace as if they were the first attempt.
• Token count and cost per model call, not just a total for the whole session.
• Latency per step, so you can tell whether a slow response came from the model, a tool call, or a retry loop.
• The final validated output and whether it matched the expected schema before being returned to the user.

This is not exotic engineering. It is the same structured logging discipline that backend teams have applied to distributed systems for a decade, applied to a new kind of call. If you already have an observability stack like Datadog or Honeycomb, pipe agent traces into it rather than standing up a separate tool nobody checks.

1. Generate a trace ID at the entry point of every agent run and pass it through every function call, tool invocation, and log statement for that run.
2. Wrap every tool call in a logging layer that captures arguments, raw result, latency, and validation status before the result reaches the model.
3. Log the full prompt at each model call, including any dynamically inserted context, not a placeholder or a hash of it.
4. Capture token usage and cost from the provider's response metadata at every call, not estimated after the fact.
5. Tag retries and fallbacks explicitly in the trace so they are visually distinct from first attempts when someone reviews the run later.
6. Ship traces to your existing observability stack with the trace ID as the correlation key, so an agent trace sits next to your regular application logs for the same request.
7. Build one dashboard showing tool call failure rate, cost per session, and latency percentiles, refreshed in near real time.
8. Test replay on a known incident before calling the instrumentation done. If you cannot fully reconstruct a run you already know the outcome of, the instrumentation is incomplete.

Logging everything and alerting on everything are different disciplines, and conflating them is how teams end up ignoring their own alerts. Alert on the small number of signals that need a human within minutes:

• Tool call failure rate above a set threshold within a rolling window, since a spike usually means an upstream dependency broke.
• Cost per session exceeding your budget ceiling, which usually means a context or retry loop bug, not organic growth.
• Schema validation failure rate on structured output, since this often precedes a customer-visible incorrect answer.
• Latency percentile breach at the p95 or p99 level, which tells you about the experience of your worst-served users, not your average one.

Everything else, the full trace detail, the token-level breakdowns, the individual tool arguments, belongs in logs for investigation, not in an alert channel. A team that pages on-call for every anomaly trains itself to mute the channel within a month, which defeats the entire purpose of alerting in the first place.

The popular argument this year is that observability tooling for agents has matured enough that teams can bolt on a third-party tracing product and consider the problem solved. Several genuinely good products exist now, and using one instead of building your own is usually the right call. But adopting a tool is not the same as having observability, and the gap between the two is where a lot of teams get a false sense of security.

A tracing product will faithfully capture whatever you instrument. It will not decide for you what counts as a failure worth alerting on, what your cost ceiling should be, or whether your traces actually contain enough detail to answer the question a customer complaint raises. I have reviewed several agents with a fully wired third-party tracing integration that still could not answer "why did this run give the wrong answer," because the team never logged the intermediate tool arguments, only the final tool result. The tool was capturing traces. The team had not decided what a useful trace needed to contain.

Buy the tool. Do not skip the design work of deciding what goes into the trace and what triggers an alert. That work is specific to your workflow and nobody can do it generically for you.

Traces answer "what happened in this specific run." An eval suite answers "does the system still work correctly across our known cases after a change." You need both, and they feed each other: a production incident found through a trace should become a new eval case, so the same failure gets caught automatically before it ships again. An eval failure should point you to the specific trace of the run that failed, so you can see exactly which tool call or context truncation caused it.

Teams that build one without the other end up either flying blind in production with a solid pre-launch test suite, or drowning in production detail with no systematic way to prevent a known failure from recurring. Both halves belong in the same review, and this is a standard part of what we check during a pilot-to-production review.

A year into a well-instrumented agent, a customer complaint or an internal question about a strange result should follow the same short path every time: pull the trace ID from the request log, open the full run, see the prompt, the tool calls, the arguments, the results, the cost, and the latency, and know within minutes whether the issue was a model reasoning error, a tool bug, a data staleness problem, or a context truncation. That single capability, being able to answer "what actually happened" quickly and confidently, is the difference between an AI system your team trusts and one everyone is quietly nervous about.

If you are running agents in production today and cannot answer that question in under ten minutes for a given complaint, that is the gap to close first, ahead of new features. It is unglamorous work and it is also the single highest-leverage investment most teams can make in an existing AI system. Our agent orchestration guide covers where tracing fits alongside the other structural decisions that keep a multi-step agent debuggable at scale.