OpenAI Session - MAF + service based conversation/response apis/Previous Response ID

[VaclavK]

Hi,

we are trying to understand nitty -gritty details of session flow between MAF and OpenAI. We currently have the following pattern in place

#6858

essentially a dedicated agent was established to own session. We see correct agents behavior but ultimately realized that we don't see the full session content (only the initial batch for a single agent in the chain) however subsequent agents were making correct decisions based on facts that could have only come from session.

This made us to investigate deeper in order to understand this at low level and hence this questions. What we see is is MAF session containing pointer to previous response id and as we run agent to agent, that id is updated. Ultimately we believe that the session at MAF is a pointer to service based "session"/response api state as maintained by OpenAI/Foundry OpenAI deployments. Is this understanding correct and or completely out of order?

in that view, the session between agents is ultimately an exchange of

previous response id to new response id and on and on

ANy documentation pointers are welcome - one pointer leading to that - apart from OpenAI docos -is e.g. https://learn.microsoft.com/en-us/agent-framework/agents/conversations/session?pivots=programming-language-csharp#service-session-id-scoping

we are also trying to conclusively prove by cross matching the full chat client hierarchy to underlying code and session id/response id code vs openai response client . slightly harder due to so many levels and package separation

[AliFozooni]

Your understanding is essentially correct for a normal Responses AsIChatClient(...) with stored output enabled. The precise model is: the MAF session holds the current head of a service-managed response chain; it is not itself the full transcript.

The path through the code is:

ChatClientAgentSession.ConversationId
    -> ChatOptions.ConversationId
    -> previous_response_id = resp_n
    <- response.id = resp_n+1
    -> session.ConversationId = resp_n+1

MAF copies the session ID into ChatOptions and later writes the returned ID back. In the OpenAI adapter, a conv_* ID is sent as conversation, while any other non-null ID (including resp_*) is sent as previous_response_id. In resp_* mode, the returned response.id becomes the next ConversationId; in conv_* mode, the stable conversation ID remains.

That also explains the apparently incomplete local session. ChatClientAgentSession persists the service ID alongside its StateBag; once a real service ID is present, MAF stops using the normal local history provider. Later calls therefore need only the new input (or tool result); the service resolves the earlier context from the chain. The function-invocation layer advances the same ID between tool-loop calls.

There are three distinct modes:

• resp_*: movable response-chain head; each call returns a new resp_*.
• conv_*: stable Conversations API object; the same conv_* is reused.
• stored output disabled: the response still has a response.id, but the adapter returns no session ConversationId; MAF/application storage must retain and replay history locally.

The repo has focused tests for both automatic response-ID continuation and mapping a non-conv_* ID to the previous response.

For your cross-agent case, mechanically sharing a compatible ChatClientAgentSession can pass this chain head, which explains the behavior you observed. It shares context, not agent configuration. In resp_* mode, OpenAI documents that prior instructions are not carried over with previous_response_id, so each current agent submits its own instructions/tools. MAF also documents sessions as agent/service-specific, so keep all agents on the same provider/project with compatible configuration, run shared-session calls sequentially, and keep durable workflow/business state outside the agent session.

To inspect a resp_* chain, the framework's integration fixture uses GetResponseInputItemsAsync(currentResponseId) plus GetResponseAsync(currentResponseId). If you want one stable, enumerable server-side object and your endpoint supports it, the Conversations sample shows creating a conv_* and passing it to CreateSessionAsync. The OpenAI conversation-state guide is the corresponding service-level documentation; it also notes that OpenAI-hosted response objects have a 30-day default retention while Conversation items do not, so a resp_* head should not be treated as permanent application memory. Check the separate retention policy for an Azure/Foundry deployment.

[VaclavK]

everything squares up, thank you for detailed response