Tracing for Agents Following One Request Across Many Calls

An agent workflow is a chain of calls — model, retrieval, tool, sub-agent. Without a trace, you have N logs and no way to reconstruct one request. Tracing is what makes an agent workflow debuggable.

Logs without a trace are a pile. A trace is the single thread that ties every call in one request together, so you can read the request end to end instead of correlating timestamps across logs.

The trace is the unit of observability for an agent workflow. One request, one trace ID, propagated across every call — model, retrieval, tool, sub-agent. Without it, you have logs; with it, you have a debuggable system.

• One trace ID per request, propagated to every call.
• Every call logs under the same trace.
• The trace is what you debug, not the call.

• The input and output of every call.
• The duration of every call.
• The decision the agent made at each step.
• The handoff to the next call, with the receipt.

The decision log is the part most teams skip — and it's the part that explains a bad output. Without it, you can see what was called but not why the agent decided what it did.

• An incident that requires correlating logs across calls by timestamp.
• A bad output with no way to reconstruct which call produced it.
• A latency problem with no way to see which call dominates.

A trace ID generated at the request start, passed to every call as context, logged with every call's output. That's the mechanism — no framework required, no fancy tooling. The discipline is propagating the ID everywhere, not the tooling you use to read it.

Tracing is the discipline that makes an agent workflow debuggable. One trace ID per request, propagated across every call, with inputs, outputs, durations, and decisions — and you can read a request end to end instead of correlating logs.