Description
FileMemoryProvider correctly generates a current memory index for each participant invocation. The index is emitted as a regular ChatRole.User message:
The following is your memory index — a list of files you have previously written.
You can read any of these files using the file_memory_read tool.
When an agent is a participant in a Magentic workflow and is selected more than once within the same workflow run, the memory-index message injected during an earlier invocation is already present in the next participant input. FileMemoryProvider then injects a new current index.
As a result, provider-generated dynamic context accumulates in the participant conversation:
First participant invocation: index v1
Second participant invocation: index v1 + index v2
Third participant invocation: index v1 + index v2 + index v3
This is not merely a token-cost issue. If file-memory contents change between invocations, the model receives stale and current indexes together. For example, an old index can reference files that have been deleted or omit files that were added later.
Expected behavior: each model call should contain one current FileMemory index. Provider-generated dynamic context should be transient, explicitly attributable to its provider, or reconciled before the next invocation. Application code should not need to identify and remove provider-generated messages by matching natural-language text.
Actual behavior: memory-index messages from prior participant invocations remain in the participant conversation and are combined with the newly generated index.
This was reproduced with ChatHistoryProvider, compaction, and message injection disabled. The Magentic manager itself has no duplicate messages; accumulation occurs only for repeatedly selected participants that use FileMemoryProvider.
Code Sample
Minimal reproduction steps:
- Create a .NET Magentic workflow with a participant that can be selected repeatedly.
- Attach the built-in
FileMemoryProvider to that participant.
- Ensure the associated file-memory store contains at least one file.
- Make the Magentic manager select the same participant at least twice in the same workflow run.
- Capture the
ChatMessage collection passed to the underlying IChatClient for each participant invocation.
Relevant built-in provider behavior:
new ChatMessage(
ChatRole.User,
"The following is your memory index — a list of files you have previously written. " +
"You can read any of these files using the file_memory_read tool.\n\n" +
indexContent)Observed captured context for the repeatedly selected participant:
Invocation 1
Messages=2; DistinctMessages=2; DuplicateMessages=0
Invocation 2
Messages=5; DistinctMessages=4; DuplicateMessages=1
DuplicateDetails=role=User; author=<none>; count=2; chars=1542;
preview='text:The following is your memory index - a list of files you have previously written. You can read any of these files using the file_memory_read tool. Memory Index-...'
Invocation 3
Messages=8; DistinctMessages=6; DuplicateMessages=2
DuplicateDetails=role=User; author=<none>; count=3; chars=1542;
preview='text:The following is your memory index - a list of files you have previously written. You can read any of these files using the file_memory_read tool. Memory Index-...'
The diagnostics canonicalize structured FunctionCallContent and FunctionResultContent using call ID, function name, arguments, and result. Therefore, the repeated index is not a false-positive collision from tool messages.
Error Messages / Stack Traces
No exception is thrown.
This is a conversation-context correctness issue. Context size and token cost grow with every re-invocation of the same Magentic participant, and stale memory indexes can coexist with the current index.
Package Versions
Microsoft.Agents.AI: 1.17.0
Microsoft.Agents.AI.Abstractions: 1.17.0
Microsoft.Agents.AI.Workflows: 1.17.0
Microsoft.Agents.AI.Workflows.Generators: 1.17.0
.NET Version
Additional Context
ChatHistoryProvider was disabled during reproduction.- Compaction was disabled during reproduction.
EnableMessageInjection was disabled during reproduction.FileAccessProvider was enabled in the same environment but does not emit the repeated memory-index text. Its tool calls and results have unique canonical fingerprints.- The Magentic manager itself consistently reported
DuplicateMessages=0.
- The behavior is not specific to a particular participant role. It appears whenever a participant using
FileMemoryProvider is selected repeatedly.
- The provider generating a fresh index for every invocation is expected. The issue is that previously generated dynamic provider context is replayed as ordinary participant conversation history.
Description
FileMemoryProvidercorrectly generates a current memory index for each participant invocation. The index is emitted as a regularChatRole.Usermessage:When an agent is a participant in a Magentic workflow and is selected more than once within the same workflow run, the memory-index message injected during an earlier invocation is already present in the next participant input.
FileMemoryProviderthen injects a new current index.As a result, provider-generated dynamic context accumulates in the participant conversation:
This is not merely a token-cost issue. If file-memory contents change between invocations, the model receives stale and current indexes together. For example, an old index can reference files that have been deleted or omit files that were added later.
Expected behavior: each model call should contain one current FileMemory index. Provider-generated dynamic context should be transient, explicitly attributable to its provider, or reconciled before the next invocation. Application code should not need to identify and remove provider-generated messages by matching natural-language text.
Actual behavior: memory-index messages from prior participant invocations remain in the participant conversation and are combined with the newly generated index.
This was reproduced with
ChatHistoryProvider, compaction, and message injection disabled. The Magentic manager itself has no duplicate messages; accumulation occurs only for repeatedly selected participants that useFileMemoryProvider.Code Sample
Minimal reproduction steps:
FileMemoryProviderto that participant.ChatMessagecollection passed to the underlyingIChatClientfor each participant invocation.Relevant built-in provider behavior:
Observed captured context for the repeatedly selected participant:
The diagnostics canonicalize structured
FunctionCallContentandFunctionResultContentusing call ID, function name, arguments, and result. Therefore, the repeated index is not a false-positive collision from tool messages.Error Messages / Stack Traces
No exception is thrown.
This is a conversation-context correctness issue. Context size and token cost grow with every re-invocation of the same Magentic participant, and stale memory indexes can coexist with the current index.
Package Versions
.NET Version
Additional Context
ChatHistoryProviderwas disabled during reproduction.EnableMessageInjectionwas disabled during reproduction.FileAccessProviderwas enabled in the same environment but does not emit the repeated memory-index text. Its tool calls and results have unique canonical fingerprints.DuplicateMessages=0.FileMemoryProvideris selected repeatedly.