Python: make FoundryMemoryProvider resolve from session.state user_id at runtime instead of falling back to session_id.#5019
Draft
tojunesa wants to merge 3 commits intomicrosoft:mainfrom
Draft
Python: make FoundryMemoryProvider resolve from session.state user_id at runtime instead of falling back to session_id.#5019tojunesa wants to merge 3 commits intomicrosoft:mainfrom
tojunesa wants to merge 3 commits intomicrosoft:mainfrom
Conversation
added 3 commits
April 1, 2026 05:43
…rom session.state user_id at runtime instead of falling back to session_id.
|
@tojunesa please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.
Contributor License AgreementContribution License AgreementThis Contribution License Agreement (“Agreement”) is agreed to by the party signing below (“You”),
|
Member
Python Test Coverage Report •
Python Unit Test Overview
|
||||||||||||||||||||||||||||||
bojunehsu
reviewed
Apr 1, 2026
| project_client: Azure AI Project client for memory operations. | ||
| memory_store_name: The name of the memory store to use. | ||
| scope: The namespace that logically groups and isolates memories (e.g., user ID). | ||
| scope: The namespace that logically groups and isolates memories. |
Member
There was a problem hiding this comment.
I prefer being more explicit and using "{{$org_id}}_{{$user_id}}" or equivalent. But this is a design decision for MAF team.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation and Context
Why is this change required?
The FoundryMemoryProvider previously required scope at init time and fell back to session_id when resolving it at runtime. Either the FoundryMemoryProvider is scoped to a single user or to a single session. Since Foundry Memory is designed as persistent cross-session memory (e.g., remembering user preferences across conversations), and the agent tie to it shall be created once and serve multiple users, the scope should be resolved at runtime.
What problem does it solve?
It removes the requirement to create a separate FoundryMemoryProvider instance per user (or accept the wrong fallback of session_id). Previously, scope was fixed at construction time, meaning a single agent serving multiple users would either need a distinct provider per user or all users would share the same memory scope. Now, scope is resolved per-request from session.state["user_id"], so one provider instance can correctly isolate memories across many concurrent users — each with their own session carrying their identity.
What scenario does it contribute to?
Multi-user agents with persistent per-user memory. A single deployed agent serves many users, each with their own AgentSession carrying session.state["user_id"]. When user A says "I'm allergic to nuts" and user B says "I love spicy food," those memories are stored under separate scopes and recalled correctly in future sessions — all through one shared FoundryMemoryProvider instance.
Description
This change updates FoundryMemoryProvider (python/packages/foundry/agent_framework_foundry/_memory_provider.py) so scope is optional and can be resolved at runtime from the active AgentSession instead of being fixed when the provider is constructed. The provider now uses session.state["user_id"] as the default memory scope, and can combine it with session.state["org_id"] when present to support tenant-aware isolation.
This aligns the provider with the intended Foundry Memory model of persistent, cross-session user memory. It allows a single agent instance and a single FoundryMemoryProvider instance to serve multiple users safely, while still keeping each user’s memories isolated. The implementation also removes the incorrect fallback to session_id, since session-scoped memory does not match the persistence scenario that Foundry Memory is meant to support.
The change includes updates to the provider logic, tests covering runtime scope resolution (python/packages/foundry/tests/foundry/test_foundry_memory_provider.py), and the sample (python/samples/02-agents/context_providers/azure_ai_foundry_memory.py) showing the recommended pattern of setting identity on session.state rather than binding scope statically during provider initialization.