Choose one owner for conversation continuity

Learning objective

Manage single-agent conversations, response chaining, and session context accumulation

Core idea

For an architect designing a single-agent experience, continuity is a state-management decision. Choose where the interaction history lives, how the next request refers to it, and what happens when that history exceeds the model’s context window. A response executes one turn; a conversation stores reusable items; an agent supplies reusable behavior. These objects have different lifetimes and responsibilities.

Microsoft Foundry supports persisted conversations, chaining from a stored response, and carrying earlier items forward explicitly. Microsoft Agent Framework also distinguishes local session history from service-managed history. Pick one authoritative continuation mechanism for a path. Copying the same history into several mechanisms makes it harder to explain what the model actually receives.

See 0.7 for the distinction between state, sessions, and memory. This lesson concerns accumulating context within one agent interaction, rather than extracting durable preferences or sharing memory between agents.

How it works

Persist conversation items

Obtain the OpenAI client through AIProjectClient.get_openai_client(). Create a durable conversation with openai.conversations.create(), then use its id as the conversation argument to openai.responses.create(). The response uses the conversation’s items and appends generated output to the same conversation. An agent_reference in extra_body selects the reusable agent configuration independently of that history.

A conversation contains more than the text shown in a chat window. Its items can include user and assistant messages, tool calls, and tool outputs. Those items explain why a later response refers to a search result or previous calculation. Treat the conversation ID as an application data reference: associate it with the authenticated customer’s interaction rather than accepting any ID the browser supplies.

You can add items explicitly with openai.conversations.items.create(). Choose whether a user message is added through that operation or supplied as the next response’s input; do not intentionally record the same turn twice. The application should distinguish a submitted message from a completed response so that reconnecting a client does not invent another user turn.

The runtime-components documentation states that when a conversation exceeds the supported context size, input context is automatically truncated. The stored conversation itself remains intact. Persistence therefore does not mean every historical item participates in every inference. A retained promise can still be absent from the model’s effective input.

Chain stored responses

When a durable conversation is unnecessary, pass the previous stored response’s ID as previous_response_id. Send the follow-up input and retain the returned response ID for the next turn. The chain refers to prior state without making the application resend every earlier item. previous_response_id requires stored responses; with store=False, carry the required output items forward explicitly instead.

This is useful when the interaction follows a linear sequence: generate a draft, ask for a correction, and request a shorter version. The ID is the continuation reference, not the draft’s display text. Sending only response.output_text as history would discard other output items that the continuation might require.

Azure OpenAI’s Responses documentation states that response data is retained for 30 days by default and documents client.responses.delete(response_id) for deleting a stored response. That is a response-retention fact, not a promise about the lifetime of every Foundry conversation. Do not design indefinite continuity around a stored-response chain without checking its lifecycle requirements.

Carry items or session state locally

For explicit input-array chaining, append response.output to the input items and then add the next user message. This gives the application control over the context supplied on each request. It also makes the application responsible for selecting valid items and bounding their accumulated size. Preserve tool interaction structure rather than flattening the array into a transcript.

With Agent Framework, AgentSession.state can hold local history, for example through InMemoryHistoryProvider in Python. For a provider with native persistent conversation support, AgentSession.service_session_id points to the service-managed state. These storage modes explain whether the next run sends local history or resumes a service-side conversation.

Persist the complete session when continuity must survive a process restart. Python provides session.to_dict() and AgentSession.from_dict(). The .NET equivalents are agent.SerializeSession(session) and agent.DeserializeSessionAsync(serialized). Saving only visible messages can lose provider state needed to resume the interaction.

Key distinctions and trade-offs

The continuation choices divide by ownership:

A stable conversation ID simplifies cross-session continuity, but history still grows. An explicit array makes context selection visible, but copying items consumes request space and requires careful handling of tool results. A session abstraction hides provider differences; it does not remove the need to understand where persistence happens.

Separate the durable record from the inference view. Keep important commitments in an application-owned record that can be reintroduced or checked, rather than relying on their location in a long transcript. See 2.2.4 for compaction and truncation. Starting another conversation is appropriate for an unrelated case; it should not silently erase an unfinished obligation.

Architecture / decision scenario

A support assistant handles a damaged shipment. The customer supplies an order number, the agent retrieves delivery evidence, and the customer returns the following day asking whether the promised replacement has shipped.

Use a persisted Foundry conversation for this case and save its ID in the authenticated case record. Each response receives conversation=CASE_CONVERSATION_ID and the case’s agent reference. The first response’s retrieval output remains part of the durable history. For an isolated rewrite of the replacement email, a separate response chain can use previous_response_id; it need not become the case’s authoritative record.

A local Agent Framework prototype uses AgentSession instead. Persist the entire session after completed turns and restore it on restart. Do not migrate by copying only the rendered chat text and assuming all tool context survives.

As the case history grows, the application checks the replacement commitment against its case record and supplies the verified order and status when needed. This protects continuity even when the service truncates inference input. The acceptance check is a follow-up after restart and after a deliberately long conversation: the agent identifies the same order and distinguishes a promised replacement from a confirmed shipment.

Common exam traps

• Treating an agent definition as the customer’s conversation history.
• Assuming stored history and model-visible context are identical.
• Continuing with display text while discarding tool and other output items.
• Confusing response retention with conversation retention.
• Restoring messages without restoring the complete provider session.
• Accumulating duplicated turns through both item insertion and response input.

What to remember

Choose one authoritative continuation path and track its reference explicitly. A conversation persists items, a response chain continues from an ID, and a local session needs full-state persistence. Accumulation creates a context-management obligation even when storage is managed by the service.

Knowledge check

References

• Microsoft, Build with runtime components in Foundry Agent Service
• Microsoft, Use the Azure OpenAI Responses API
• Microsoft, Storage