An agent trace should answer one operational question quickly: how did this request become that outcome? Model calls alone cannot explain a run that also retrieves context, executes tools, retries work, and crosses service boundaries.
Start with a stable run identity
Create a run ID at the application boundary and propagate it through queues, services, model clients, and tools. Each operation becomes a child span with its own timing, status, and release metadata.
The resulting hierarchy preserves causality. Engineers can move from a failed outcome to the exact model or tool step responsible without correlating timestamps across separate products.
Capture decisions, not everything
Useful traces include model and prompt versions, tool names, response status, token usage, validation outcomes, and application-defined metadata. Raw prompts and documents should follow explicit capture and redaction policies.
Connect traces to releases
Every run should identify the code, prompt, configuration, and model release that served it. This turns traces into evidence during a rollout: a team can compare canary and stable versions using the same production signals.
Make outcomes first-class
Latency and error rate matter, but an agent may return a fast, technically successful response that fails the task. Add outcome events such as completion, escalation, validation pass, or user correction so operational health reflects product behavior.