.NET: Give a hosted agent a single source of conversation history by rogerbarreto · Pull Request #7525 · microsoft/agent-framework

rogerbarreto · 2026-08-05T10:34:22Z

Motivation & Context

A hosted agent received the same conversation twice, and quietly kept a second copy of it.

Four defects, all in that path:

#	Defect	Consequence
1	The handler put the service's turns into the input while the agent loaded the same turns through its provider	the model saw the conversation twice, and paid for it
2	Service items carry no chat-history source marker, so the provider's re-store filter did not catch them	a second copy grew inside the session every turn, or inside a custom store (Cosmos, Valkey)
3	"Is this a resume?" was answered by looking for state on the session, but the handler writes the caller's identity there just before asking	the first turn of a conversation looked like a resume, so its history was never fetched and the agent answered blind. Hosted only: locally there is no identity to write
4	`store=false` reached the Foundry service but never the service the agent's own chat client calls	that service kept recording the conversation and reporting an id, so a caller opting out still got a stored conversation

Description & Review Guide

What are the major changes?

The handler stops feeding history to an agent that loads it through a ChatHistoryProvider,
and writes into that provider instead, so there is one source per turn.

Defect	Fix
1	the handler no longer adds prior turns for such an agent, and only ever writes into the stock `InMemoryChatHistoryProvider` the agent made for itself, so an agent given a provider keeps sole control of its storage
2	history the handler still passes as input, for an agent with no provider, is marked as chat history so the existing filter catches it
3	`AgentSessionStore.GetSessionAsync` returns `null` when nothing is stored, so a non-null result answers "this is a resume" on its own. `GetOrCreateSessionAsync` is added for callers that just want a usable session, written in terms of `GetSessionAsync` so a store overriding one gets the other free
4	`store=false` is carried to the chat client through `CreateResponseOptions.StoredOutputEnabled`. Only that direction travels: `store=true` would either force storage on a container that turned it off on purpose, or change nothing

Where a conversation lives. Two places can hold one, never both at once: the Responses API
the agent's chat client calls, which returns a conversation id when it does and makes the agent
switch its provider off by itself; and in memory, the stock InMemoryChatHistoryProvider
inside the session the container persists. The Foundry service is a third and different
place: the platform hosting the agent, which records or not according to the request's store,
and which the handler reads from when a conversation has to be recovered. "Reads from Foundry"
below means one call, ResponseContext.GetHistoryAsync.

Each node is one turn and shows what arrives, what the handler does about the conversation,
whether in memory is on, and what the model receives. The handler line covers only the
conversation: every turn it also loads and saves the session, converts the input, builds the chat
options and runs the agent.

Stored all the way

graph LR
    A1["<b>Turn 1</b> · store=true<br/>handler: reads Foundry, finds nothing<br/>in memory: on, empty<br/>model receives: question 1"]
    A2["<b>Turn 2</b> · store=true + conversation id<br/>handler: session carries the id, so it does not read<br/>from Foundry, and clears memory at the end of the turn<br/>in memory: <b>off</b><br/>model receives: question 2, and the Responses API<br/>adds turn 1 through the conversation id"]
    A3["<b>Turn 3</b> · store=true + conversation id<br/>handler: same as turn 2, no read from Foundry<br/>in memory: <b>off</b><br/>model receives: question 3, and the Responses API<br/>adds turns 1 and 2"]

    A1 -->|"Responses API returns a conversation id.<br/>it arrived before storing time,<br/>so in memory stored nothing"| A2
    A2 -->|"conversation id stays on the session"| A3

Turn 1 is deceptive. In memory is on for it, because no conversation id exists yet, but it serves
nothing. By the time the turn ends the id has arrived, and the agent resolves the provider to
null before asking it to store, so nothing is stored. From there on the Responses API owns the
conversation and in memory never comes into play again.

Stored, then not

graph LR
    B1["<b>Turn 1</b> · store=true<br/>handler: reads Foundry, finds nothing<br/>in memory: on, empty<br/>model receives: question 1"]
    B2["<b>Turn 2</b> · store=false + conversation id<br/>handler: drops the conversation id from the session,<br/>reads turn 1 from Foundry, writes it into memory<br/>in memory: on, holding turn 1<br/>model receives: turn 1 + question 2"]
    B3["<b>Turn 3</b> · store=false<br/>handler: memory already holds the conversation,<br/>so it does not read from Foundry<br/>in memory: on<br/>model receives: turns 1 and 2 + question 3"]

    B1 -->|"Responses API returns a conversation id.<br/>Foundry recorded turn 1"| B2
    B2 -->|"no conversation id comes back.<br/>memory stores turn 2"| B3

The switch happens on turn 2 and has three parts: store=false is sent to the Responses API as
well, so it records nothing and returns no id; the conversation id on the session no longer names
anything that is still growing and cannot be cleared, so the session is cloned without it, on
this turn only; and in memory wakes up empty, so the handler copies what Foundry still holds.
From turn 3 on, memory is the only source and Foundry is never read again.

Stored, then not, then trying to go back

graph LR
    C1["<b>Turn 1</b> · store=true<br/>handler: reads Foundry, finds nothing<br/>in memory: on, empty<br/>model receives: question 1"]
    C2["<b>Turn 2</b> · store=false + conversation id<br/>handler: drops the conversation id from the session,<br/>reads turn 1 from Foundry, writes it into memory<br/>in memory: on, holding turn 1<br/>model receives: turn 1 + question 2"]
    C3["<b>Turn 3</b> · store=true<br/>handler: refuses the request before calling the model<br/>conversation_not_stored, HTTP 400"]

    C1 -->|"Foundry recorded turn 1"| C2
    C2 -->|"Foundry recorded nothing.<br/>memory stores turn 2"| C3

Foundry holds turn 1 and nothing after it. Recording turn 3 would leave a gap in the stored
conversation, jumping from turn 1 straight to turn 3, and anyone reading it back would get an
answer to a question that is not there. The opposite direction is allowed: going from stored to
unstored only moves the conversation into the session, and nothing is left half written.

What is the impact of these changes?

Hosted agent	Before	After
`ChatClientAgent`, no provider of its own	conversation sent twice, session copy growing every turn	sent once, session holds only what nothing else holds
`ChatClientAgent` with its own provider	service history mixed in and written to that store	its own store is the single source
Workflow hosted as an agent	first turn of a known conversation lost its history when hosted	receives it, marked as history
Restarted container or second replica	history refetched into the input every turn	read once into the provider, then carried by it
Caller sending `store=false`	the chat client's service still recorded the conversation	nothing is recorded anywhere

The test for who loads history is whether the agent is a ChatClientAgent, the only kind in the
framework that drives a provider through InvokingAsync and InvokedAsync. A hosted workflow
does own a WorkflowChatHistoryProvider, but drives it through its own methods for resuming
rather than that pair. Since the protocol is public, an agent written outside this repo could
drive one and would then see the conversation twice; feeding it is still the safer default,
because an agent that keeps nothing of its own would otherwise start every turn with no memory,
and the marking already stops those messages being stored as new.

AgentSessionStore here is the one in Microsoft.Agents.AI.Foundry.Hosting, which partitions
per user; the separate type of the same name in the framework's own hosting package is untouched.
GetSessionAsync changes its return type and its meaning. The type is public, but the handler is
its only caller and the package is still in preview, so both in-box stores are updated here and
nothing else has to follow.

What do you want reviewers to focus on?

Whether refusing a stored turn after an unstored one is the right call, or whether the kept turns
should be replayed as input so the service learns them instead.

Related Issue

N/A

Contribution Checklist

The code builds clean without any errors or warnings
All unit tests pass, and I have added new tests where possible
The PR follows the Contribution Guidelines
This PR is linked to an issue and there is no other open PR for this issue (see Related Issue above).
This is not a breaking change. If it is a breaking change, add the breaking change label (or add "[BREAKING]" to the title prefix, before or after any language prefix) — a workflow keeps the label and title prefix in sync automatically.

The handler used to fetch the platform conversation history and prepend it to the input of every turn. For a ChatClientAgent that runs in parallel with its own chat history provider, so the conversation had two sources at once. It also had a hidden cost: platform items carry no chat-history source marker, so the agent's provider stored them again as if this turn had written them, leaving a second copy of the conversation inside the persisted session that then diverges from the platform. Make the chat history provider the single source for a ChatClientAgent: - Add FoundryChatHistoryProvider, which reads the conversation through ResponseContext.GetHistoryAsync (it already resolves previous_response_id and the conversation the request belongs to) and stores nothing, because the platform persists the response items itself. An instance is created per request because it holds that request's context, and it is passed as a run-scoped override so the host does not have to mutate the agent. - Register it only when the agent was created without a chat history provider. When one was supplied at construction, that provider owns the conversation and the platform history is not used at all. - Stop adding the platform history to the input for a ChatClientAgent, since the provider now delivers it. A workflow hosted as an agent is not a ChatClientAgent and has no provider pipeline, so it keeps receiving the platform history from the handler exactly as before.

Cover the three symptoms the previous handler produced, each verified to fail when the handler is reverted to fetching the platform history into the turn input: - the conversation the service already keeps was copied into the persisted agent session by the default in-memory history provider; - a custom history provider was asked to write that same conversation into its own database, because platform items carry no chat-history source marker and so look like content this turn produced; - an agent with its own provider received both that provider's history and the platform's in a single request. Also state precisely, in the provider's remarks, why nothing is written back: for a stored request the response orchestrator hands the finished response to its responses provider, which persists the input and output items that a later turn then reads back through GetHistoryAsync; for a non-stored request nothing is persisted and nothing is readable, so the request is self-contained either way.

A conversation can mix turns the service stores with turns it does not. History is resolved from previous_response_id or the conversation regardless of the current request's store flag, so an unstored turn still reads the stored ones back, but the service records nothing for it and a later turn would never see it again. Reading the platform history through FoundryChatHistoryProvider alone lost those turns: from the second turn onwards the handler treats the session as a resume and stops feeding history in, and the provider kept nothing of its own, so an unstored turn simply vanished from the conversation. A regression test drives three turns of one conversation, the first stored and the rest not, and without this change the model receives only [second question, ok, third question]: the stored opening turn is gone. Give the provider both halves instead of choosing one: - reading returns what the service serves, followed by the turns kept in the session, which are by definition later than anything the service recorded; - writing keeps a turn only when the service was not asked to store it, so a stored turn is never duplicated and an unstored one is never lost. The turns are held in the agent session under the provider's own state key, so they travel with the session the host already persists.

A conversation can move between stored and unstored turns, and the unstored ones live only in the agent session. Going back to a stored turn after that would have the service record it on top of turns the service never saw, so anyone reading the conversation back from the service would find an answer with no question. Refuse it before the model is called instead of writing that gap. Cover the whole shape with a walkthrough of nine turns over one conversation and three provider instances, each with its own session: - an instance that never took an unstored turn starts from the turn the service last saved, and does not see another instance's unstored turns; - an instance that did keeps reading the saved turns and adds its own on top; - asking such an instance for a stored turn is refused, twice, while unstored turns keep working; - a turn stored from one instance does not appear for another, because it sits on a different branch of the conversation and so is not among the turns leading to what that other instance last saved.

The turns the service was not asked to store are written into the agent session's state bag under this provider's own state key, and a new provider is built for every request, so nothing is held on the provider object itself. The walkthrough named its three threads after provider instances, which read as if the object carried the memory. Name them after the sessions they are, and add a test that pins the behaviour down: a turn kept through one provider object is read back by a different one given the same session, and is absent for one given another session.

The session decides what is kept, but the provider still decides two things: which service-side conversation is read, because it holds the request's response context, and whether the turn is kept at all, because it holds the request's store flag. Add two tests that separate those from the session: - two providers reading one session, each built for a request of a different conversation, return the same kept turn behind different served turns; - two providers writing to one session, one for a stored request and one for an unstored one, leave only the unstored turn behind.

The comment stated that a workflow hosted as an agent has no provider pipeline without saying what that means. It derives from AIAgent directly, so it never calls a ChatHistoryProvider and does not read the run options' additional properties: the provider could not reach it even if it were registered.

The handler decided that a turn was resuming an existing conversation by looking for state on the session. That reading broke once the handler itself started writing to the session before the check: it records the caller's identity there, so a session created moments earlier already carried state and the very first turn of a conversation looked like a resume. Its history was then never fetched, and the agent answered knowing nothing of a conversation the service was already holding. It only showed up when hosted, because running locally there is no identity to record. Let the store answer the question instead. GetSessionAsync now returns null when nothing is stored rather than quietly handing back a new session, so a non-null result means a prior turn established this session and nothing else has to be inferred. Callers that just want a usable session can use the new GetOrCreateSessionAsync, which is written in terms of GetSessionAsync so a store overriding one gets the other for free. Both store implementations and their tests follow the plain-lookup contract: a miss creates nothing, deserializes nothing, and touches no directory.

FoundryChatHistoryProvider is internal, so the attribute reached no caller: the marker exists to warn people consuming the public surface. It also does not follow from the base type, which does not carry one, and most internal types in this package have none either. Removing it leaves two usings behind, so they go as well.

An agent refuses a second history manager once the model reports a conversation id of its own, which happens as soon as the container lets the model keep the conversation. The guard is meant for an application that configured a provider by hand and would otherwise end up with two of them. Here the host is the one supplying the provider, deliberately and for every turn, so the guard was rejecting the arrangement it is hosting: the first turn failed while streaming, and every later one failed before reaching the model at all. Turn the three conflict settings off on the agent the host is serving, and let the provider decide what reaches the model. A test drives two turns of one conversation against a model that reports a conversation id and asserts both complete.

A request asking the hosting service not to store the response was honoured there and nowhere else, so the service behind the agent's own chat client kept recording the conversation and reporting an id for it. A caller opting out of storage still ended up with a stored conversation, and the container went on continuing it. Only that direction travels. Carrying store=true across would either force storage on a container whose author turned it off on purpose or change nothing, since storing is already the default.

The host no longer supplies a chat history provider of its own. It writes the turns the service holds into the provider the agent already created for itself, and only when that is the stock in-memory one, so an agent given a provider keeps sole control of its storage and the model receives the conversation once. A conversation the caller stops asking the service to store moves into the session state and stays there. The session's conversation id no longer names anything the service records and cannot be cleared, so the session is cloned without it on that single turn. Asking for a stored turn afterwards is refused: the service would record a turn whose predecessors it does not hold. An agent that does not read history through a provider, a hosted workflow for example, is still given its prior turns as input, now marked as chat history so no provider along the way stores them as new.

Copilot

🟡 Changes recommended

The store=false propagation via ChatOptions.RawRepresentationFactory can suppress agent/container RawRepresentationFactory behavior due to ChatClientAgent’s factory chaining semantics, risking incorrect request shaping.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

This review doesn't count toward merge requirements. Sign up for the private preview to control whether Copilot approvals count.

Pull request overview

This PR adjusts the Foundry hosted-agent request pipeline to ensure each turn’s conversation history comes from exactly one place (service history, provider/session state, or the model’s own conversation id), preventing duplicate replay/storage and fixing incorrect “resume” detection.

Changes:

Update hosted session store semantics so GetSessionAsync is a pure lookup returning null when nothing is persisted, and add GetOrCreateSessionAsync for callers that want a usable session.
Rework AgentFrameworkResponseHandler history routing: preload service history into the default InMemoryChatHistoryProvider for ChatClientAgents, stamp replayed service history as ChatHistory when passed as input, and use store presence (not session state) as the resume signal.
Propagate store=false into chat-client options via CreateResponseOptions.StoredOutputEnabled = false.

File summaries

File	Description
dotnet/tests/Microsoft.Agents.AI.Foundry.Hosting.UnitTests/FileSystemAgentSessionStoreTests.cs	Updates tests to reflect `GetSessionAsync` now returning `null` on cache miss and adds coverage for `GetOrCreateSessionAsync`.
dotnet/tests/Microsoft.Agents.AI.Foundry.Hosting.UnitTests/AgentFrameworkResponseHandlerTests.cs	Adds regression coverage for resume detection, single-source history routing, and stored/unstored conversation continuity.
dotnet/src/Microsoft.Agents.AI.Foundry.Hosting/InputConverter.cs	Attempts to forward `store=false` to the underlying chat client via `RawRepresentationFactory`.
dotnet/src/Microsoft.Agents.AI.Foundry.Hosting/InMemoryAgentSessionStore.cs	Makes `GetSessionAsync` a pure lookup returning `null` when not found.
dotnet/src/Microsoft.Agents.AI.Foundry.Hosting/HostedSessionJsonUtilities.cs	Adds a serialization shape to clone a `ChatClientAgentSession` without a `conversationId`.
dotnet/src/Microsoft.Agents.AI.Foundry.Hosting/FileSystemAgentSessionStore.cs	Makes `GetSessionAsync` return `null` on missing/empty session file.
dotnet/src/Microsoft.Agents.AI.Foundry.Hosting/AgentSessionStore.cs	Updates `GetSessionAsync` contract to nullable and introduces `GetOrCreateSessionAsync`.
dotnet/src/Microsoft.Agents.AI.Foundry.Hosting/AgentFrameworkResponseHandler.cs	Centralizes conversation ownership per turn, fixes resume detection, and prevents history duplication/storage.

Review details

Files reviewed: 8/8 changed files
Comments generated: 1
Review effort level: Lite

We're testing this review assessment. Please use 👍 or 👎 to tell us if it's correct.

github-actions

Automated Code Review

Reviewers: 2 | Confidence: 57% | Result: All clear

Reviewed: Correctness, Test Coverage

Automated review by rogerbarreto's agents

ChatClientAgent chains a request's raw representation factory with the agent's by taking the agent's only when the request's returns null. The factory added for an unstored turn always answers, so anything the container configured on the agent's ChatOptions was silently dropped for that turn. The agent's factory is now invoked first and its result is what carries the setting. A result that is not a CreateResponseOptions belongs to some other chat client, which has no notion of storing a response, so it is handed back untouched.

westey-m · 2026-08-05T12:04:34Z

+                var responseOptions = configuredByTheAgent as CreateResponseOptions ?? new CreateResponseOptions();
+                responseOptions.StoredOutputEnabled = false;
+                return responseOptions;


What happens if someone is using Chat Completion rather than Responses, or some other non-openai protocol?

westey-m · 2026-08-05T12:20:38Z

+
+            if (session is ChatClientAgentSession { ConversationId: not null })
+            {
+                session = await CloneSessionWithoutConversationIdAsync(agent, session, cancellationToken).ConfigureAwait(false);


I'm not sure we should be doing this. it's essentially working around the not-supported downstream service stored chat history scenario by re-setting the downstream conversation id on each request. I'd prefer just throwing instead. After all, storing service side has no benefit in this case, but may incur additional expense, and all inference services with service storage also allow client storage.

This is currently supported by the Response API today, you can just use store=true and shift to false pointing to the original conversation (stored previsouly)

It has the benefit of storing the conversation server side that you can just reuse in a new session.

This allows the use of an existing conversation with store=false, dropping this we are essentially blocking this flexibility. (Allowing use the session as a fork from an existing conversation).

Whether we support store=true/false as input into the hosted agent service is unrelated to whether we support store=true for the responses service used by the ChatClientAgent hosted by the agent service.

I'm suggesting that we never support service storage for the downstream inference service, since it clashes with the chat history storage already provided by the hosting layer.

westey-m · 2026-08-05T12:31:30Z

+        // drives one and would then see the conversation twice. Erring the other way is worse, because an
+        // agent that keeps nothing of its own would start every turn with no memory at all, and the
+        // marking already stops a provider from writing these messages down as if they were new.
+        var agentReadsHistoryFromAProvider = chatClientAgent is not null;


I think it might be simpler to create a small override CHP that doesn't store messages in state, and rather just in a field on the CHP:

We wouldn't really need to check if the agent is a ChatClentAgent anymore

We can create an new CHP with no messages

We can set this empty CHP in additional properties as an override (it will be ignored by anything but a ChatClientAgent)

We pass the chat history and new messages into the run as input messages

That override CHP is used during this run, while any CHP on the agent already is ignored and the override is discarded at the end of the run. For the next request, a new one is created.

This also means, we don't need to do any reset of messages in the session after the run, or any setting of messages in the session.

The refusal was only tested on a conversation the service never stored. Reaching it from a stored one goes through the turn that rebuilds the session without its conversation id, so the mark saying the conversation left the service has to survive that rebuild to be found on the next turn.

rogerbarreto added 12 commits July 30, 2026 17:30

Copilot AI lite review requested due to automatic review settings August 5, 2026 10:34

rogerbarreto temporarily deployed to github-app-auth August 5, 2026 10:34 — with GitHub Actions Inactive

rogerbarreto temporarily deployed to integration August 5, 2026 10:34 — with GitHub Actions Inactive

Copilot started reviewing on behalf of rogerbarreto August 5, 2026 10:35 View session

agent-framework-automation Bot added the .NET Usage: [Issues, PRs], Target: .Net label Aug 5, 2026

rogerbarreto marked this pull request as ready for review August 5, 2026 10:35

rogerbarreto temporarily deployed to github-app-auth August 5, 2026 10:35 — with GitHub Actions Inactive

Copilot AI reviewed Aug 5, 2026

View reviewed changes

Comment thread dotnet/src/Microsoft.Agents.AI.Foundry.Hosting/InputConverter.cs

github-actions Bot reviewed Aug 5, 2026

View reviewed changes

rogerbarreto temporarily deployed to github-app-auth August 5, 2026 11:02 — with GitHub Actions Inactive

rogerbarreto temporarily deployed to integration August 5, 2026 11:02 — with GitHub Actions Inactive

westey-m reviewed Aug 5, 2026

View reviewed changes

rogerbarreto temporarily deployed to github-app-auth August 5, 2026 12:32 — with GitHub Actions Inactive

rogerbarreto temporarily deployed to integration August 5, 2026 12:32 — with GitHub Actions Inactive

Navigation Menu

Uh oh!

.NET: Give a hosted agent a single source of conversation history - #7525

.NET: Give a hosted agent a single source of conversation history#7525
rogerbarreto wants to merge 14 commits into
microsoft:mainfrom
rogerbarreto:features/hosted-chat-history-provider

rogerbarreto commented Aug 5, 2026 •

edited

Loading

Uh oh!

Copilot AI left a comment

Uh oh!

Uh oh!

github-actions Bot left a comment

Uh oh!

westey-m Aug 5, 2026 •

edited

Loading

Uh oh!

westey-m Aug 5, 2026 •

edited

Loading

Uh oh!

rogerbarreto Aug 5, 2026 •

edited

Loading

Uh oh!

westey-m Aug 5, 2026

Uh oh!

westey-m Aug 5, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

rogerbarreto commented Aug 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Motivation & Context

Description & Review Guide

Related Issue

Contribution Checklist

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

🟡 Changes recommended

Uh oh!

Uh oh!

github-actions Bot left a comment

Choose a reason for hiding this comment

Automated Code Review

Uh oh!

westey-m Aug 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

westey-m Aug 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rogerbarreto Aug 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

westey-m Aug 5, 2026

Choose a reason for hiding this comment

Uh oh!

westey-m Aug 5, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

rogerbarreto commented Aug 5, 2026 •

edited

Loading

westey-m Aug 5, 2026 •

edited

Loading

westey-m Aug 5, 2026 •

edited

Loading

rogerbarreto Aug 5, 2026 •

edited

Loading