2.2.2. Threads, Runs, and Conversation State
💡 First Principle: A conversation is the persistent container for the dialogue (the state); a response is one execution of the agent against it (the action), and a single response may take several tool-calling steps before it completes. The conversation outlives any one response. The Classic API calls these a thread and a run — expect either pair of names.
This distinction is heavily testable because it controls how memory and concurrency work. In the current Foundry Agent Service, built on the Responses API, you create a conversation once per dialogue and call responses.create with the agent reference, the conversation ID, and the new user input; the turn's items (messages, tool calls, tool outputs) are appended to the conversation. When the agent needs one of your function tools, the response returns a function_call item; your app runs the function and sends a function_call_output item with the matching call_id in a follow-up response on the same conversation. Conversation memory is simply the accumulated items in the conversation — the agent "remembers" because the conversation persists, not because the model has memory of its own. The Classic API, still common in older code and samples, expresses the same model as threads and runs: you append messages to a thread and start a run, which is asynchronous and progresses through states (queued → in-progress → possibly requires-action when a tool must be executed → completed), as the diagram shows.
⚠️ Exam Trap: "A conversation and a response (or 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 conversation (Classic: thread) — the persistent state. If it asks why a single execution involved multiple tool calls, that's one response (Classic: run) with multiple steps. Concurrency questions (two dialogues at once) are about separate conversations (or threads).
Reflection Question: Why does putting two unrelated customer dialogues on the same conversation (or Classic thread) cause the agent to "leak" context between them, and what's the correct design?
