A single agent turn that ends in the right answer can still be a debugging nightmare if it took four tool calls to get there and one of them was slow, one of them silently returned the wrong data, and you have no way to tell which was which after the fact. Chat logs show you the final message. They don't show you that the search_orders call took 4.1 seconds while everything else took under 200ms, or that the model called get_invoice twice with the same argument because the first tool_result never made it back cleanly. Observability is what turns "the agent was slow" or "the agent got it wrong" from a shrug into an answer you can point at.
Lesson 5 built the tool-using loop itself: call the model, read tool_use blocks off the response, execute them, feed tool_result blocks back, repeat until the model stops asking for tools or a hard iteration cap is hit. That loop is the thing this lesson instruments. Every iteration is one model call and zero or more tool executions, and a production agent might run that loop thousands of times a minute across different users, different tools, and wildly different latencies. Without a trace of what happened inside each iteration, you're debugging a distributed system with your eyes closed.
This lesson is deliberately scoped to one turn's execution, not the whole agent's quality. Lesson 25 covered whether the model picked the right tool; this lesson assumes tool selection is fine and asks a different question — when something goes wrong or goes slow, can you reconstruct exactly what happened, in what order, with what inputs, and how long each step took, without adding a print statement and reproducing the bug live. That reconstruction is what a trace is for.