2.2.2. Threads, Runs, and Conversation State
💡 First Principle: A thread is the persistent conversation container (the state); a run is one execution of the agent against that thread (the action), and a single run may take several internal tool-calling steps before it completes. The thread outlives any one run.
This distinction is heavily testable because it controls how memory and concurrency work. You create a thread once per conversation, append user messages to it, and start a run to get the agent to respond. The run progresses through states (queued → in-progress → possibly requires-action when a tool must be executed → completed). Conversation memory is simply the accumulated messages in the thread — the agent "remembers" because the thread persists, not because the model has memory of its own.
⚠️ Exam Trap: "A thread and a run are the same thing." They are not. If a scenario asks how the agent remembers earlier turns, the answer is the thread (persistent state). If it asks why a single response involved multiple tool calls, that's one run with multiple steps. Concurrency questions (two conversations at once) are about separate threads.
Reflection Question: Why does putting two unrelated customer conversations on the same thread cause the agent to "leak" context between them, and what's the correct design?
