Why every agent run needs a timeline

The first agent demo everyone builds ends at the reply. A user asks something, the model answers, and the room nods. Then it goes to production and the interesting part starts: the agent calls a tool, the tool returns a 429, the retry succeeds, the second tool times out, and the customer gets nothing.

None of that is visible in a chat log. What you need is the shape of the run — the steps in order, each with its input, its output, its duration and its error.

When a run fails, the useful question is never "what did the model say". It is "which step stopped, and what did it have to work with". Storing the payload at each boundary turns a support ticket into a five-second answer.

This costs storage, which is why retention is configurable. It is worth it: the alternative is reproducing the failure by hand, and agent failures are frequently unreproducible.

A design that treats failure as an edge case produces interfaces where a failed run looks like a successful one with a red badge. The failed step should be the thing your eye lands on, with the reason next to it, and the steps after it marked as skipped rather than silently absent.