Seeing what it did
When an agent gives a strange answer, the question is always the same: what did it actually do? Printing the state gets you part of the way. A trace gets you the rest.
You have been debugging by printing all course long, and for a two node graph that is enough. It stops being enough at the point where a model chose a tool for reasons you cannot see.
Turning it on
Two environment variables. There is no code change at all, and nothing to import.
export LANGSMITH_TRACING=true
export LANGSMITH_API_KEY=your-key-hereRun your graph after that and every run is recorded. The key is free for personal use, and the recording happens in the background, so your program is not waiting on it.
What a trace shows you
One run, opened up. Every node in the order it ran, how long each took, and the state going in and out of each one.
- The exact prompt. Not what you meant to send, what was actually sent, after every f-string and every message list was assembled.
- The tool calls. Which tool the model asked for, with which arguments, and what came back.
- Every trip round a loop. An agent that went round four times shows four passes, so you can see which one went wrong.
- Tokens and cost. Per run, which is how you find out that trimming from lesson 21 was not optional.
The single most useful of those is the first one. A surprising number of agent bugs are a prompt that does not contain what its author assumed, and it is invisible until you look at the recorded version.
The three things it is actually for
| Question | What you look at |
|---|---|
| Why did it pick that tool? | The prompt, and the tool descriptions it was given |
| Why is this slow? | The timing on each node, which is usually one model call |
| Why is this expensive? | The token count, which is usually the conversation getting long |
Notice that two of those three are answered by things this course already taught you to control. The docstring from lesson 16 decides tool choice, and trimming from lesson 21 decides cost. The trace tells you which one to go and fix.
If you would rather not send anything anywhere
Tracing sends your runs, prompts included, to a hosted service. That is a decision to make deliberately, and there are two alternatives.
Stream with stream_mode="updates", from lesson 25, and log each step yourself. Or run the server from the last lesson and use its browser view, which shows the same node by node picture without leaving your machine.
You are done
This started as a function that took a dictionary. You have built a support agent that uses tools, remembers, and asks permission before spending money, and a documentation assistant that answers from your own text and admits when it cannot.
Everything left in the official documentation is either reference, internals, or a second way to write what you can already write. It will read like a manual now, which is the point.
- Turn tracing on and run the assistant, then open the run and read the prompt it built.
- Run the agent loop from lesson 18 and count the passes in the trace.
- Compare the token count of a short conversation with a long one.
Little by little, you're building something great.