How does Microsoft Foundry Agent Service handle conversation state?

Question

How does Microsoft Foundry Agent Service handle conversation state?

Wade Gausden 166

The question is from a small knowledge check on the training "Develop AI agents with Microsoft Foundry and Visual Studio Code"

User's image

The answer in this case is option C, that the Responses API automatically manages conversation context.

However, and I could be mixing up resources or terms, in the training one step earlier it has the following :

User's image

In the Lab, we use a Conversation_Id between turns to track state, which seems to work just fine. So........ I guess the API is "stateless" as we have to pass the conversation id back each time, but then it's also confusing in the documentation to say we must store conversation history when that isn't realllyyy the case.

0 comments

1 answer

Your answer

Answer 1

Both statements can be true because Foundry Agent Service separates responses, conversations, and sessions.

A response is one unit of execution.
A conversation persists history across turns.
A session persists sandbox state such as $HOME and uploaded files.

For Responses protocol agents:

Conversation continuity does not come from agent_session_id.
It comes from either previous_response_id or a conversation ID.
If a conversation ID is used, the platform stores the message history for that conversation and reuses a stable session automatically.

That is why the lab works when passing conversation_id between turns: the conversation history is being persisted by the service under that conversation ID.

The part that says the Responses API is stateless refers to the call pattern, not to whether the platform can store history. A single responses.create call does not automatically know prior turns unless the application supplies a threading mechanism such as:

previous_response_id, or
conversation

So the practical distinction is:

Without previous_response_id or conversation_id: each call is effectively standalone.
With conversation_id: the platform-managed conversation history is reused across turns.

For Invocations protocol agents, the platform does not store conversation history; the container code manages state itself. In that model, the statement about storing conversation history in the client or application is accurate.

So the clean interpretation is:

The quiz answer is correct for the Responses-based conversation model: Foundry can automatically manage conversation context when a conversation is used.
The “stateless Responses API” wording means each request must still reference prior context explicitly; the service does not infer it from the session alone.
The “store conversation history in your client” guidance applies when using stateless response chaining or when not using platform-managed conversations.