Can a Single Foundry Agent Use Multiple Memory Stores to Scale Beyond the 100-Scope Limit?

Question

Can a Single Foundry Agent Use Multiple Memory Stores to Scale Beyond the 100-Scope Limit?

Mohamed, Rihan 60

Microsoft documentation currently lists a maximum of 100 scopes per Memory Store.

If an application needs to support more than 100 users, one possible approach would be to partition users across multiple Memory Stores:

Users 1–100       → Memory Store A
Users 101–200     → Memory Store B
Users 201–300     → Memory Store C
Users 301–400     → Memory Store D

For example, the application would determine the user's ID and route the user to the appropriate Memory Store. Each user's memories would remain within the assigned Memory Store.

I would like to confirm whether this architecture is actually supported by Microsoft Foundry Memory.

Specifically:

Can a single Foundry Agent use multiple Memory Stores?
Can the application select which Memory Store to use based on the user's ID?
Is this a supported way to scale beyond the 100 scopes per Memory Store limit?
If yes, is there an official Microsoft implementation pattern or documentation for this approach?
If a single agent cannot use multiple Memory Stores, what is the recommended Microsoft-supported architecture for an application that needs more than 100 user scopes?

I am specifically looking for confirmation on whether multiple Memory Stores can be used with a single agent/application, rather than whether multiple Memory Stores can be created.

Any official documentation or guidance would be appreciated.

0 comments

2 answers

Your answer

Answer 1

Hi Mohamed, Rihan ,

Thanks for the thoughtful question.

Based on the current Memory documentation, Microsoft explicitly documents a quota of 100 scopes per memory store and states that memory data is organised within a memory store and scope. The documentation also notes that applications can interact with memory through either the Memory Search Tool or the Memory Store APIs.

What is documented is that low-level Memory Store APIs provide direct interaction with memory stores and memory records, giving applications greater control over memory management.

Therefore, based on the currently available documentation:

Can a single agent use multiple memory stores? I couldn't find documentation confirming this capability. The published examples and guidance describe memory usage against a specific memory store.
Can an application choose which memory store to use? The Memory Store APIs provide direct control over memory operations, so applications manage which store they interact with. However, Microsoft does not currently document a specific user-sharding architecture as an official pattern.
Is using multiple memory stores the supported way to scale beyond 100 scopes? I couldn't find documentation that explicitly states this is the recommended or supported scaling approach.
Is there official documentation for a multi-store architecture? I was unable to locate any published guidance describing a memory-store partitioning or sharding pattern.
What is the recommended architecture for more than 100 user scopes? The current documentation identifies the quota but does not describe a recommended architecture for scenarios that exceed the 100-scope-per-store limit.

As Memory is currently in preview, there is no published guidance for this scenario today. We recommend working within the documented limits and monitoring future documentation updates for any supported scalability patterns or enhancements.

Answer 2

Hello @Mohamed, Rihan

This is a good question because the 100 scopes limit applies to each Memory Store, not necessarily to the application as a whole.

Microsoft currently documents these Memory limits:

Maximum scopes per Memory Store: 100
Maximum memories per scope: 10,000
Search operations: 1,000 requests/minute
Update operations: 1,000 requests/minute

However, I would distinguish between what the application can architect and what a single Foundry agent's memory tool configuration natively supports.

When using the Memory Search tool with an agent, the tool configuration references a specific memory_store_name and scope. Microsoft recommends creating a dedicated Memory Store for each agent and using scopes to isolate individual users.

For example, the documented configuration follows this pattern:

MemorySearchPreviewTool(
    memory_store_name=memory_store_name,
    scope="{{$userId}}"
)

So I don't see a documented feature where a Memory Search tool automatically selects between Store A, Store B, Store C, etc., based on the user ID.

That said, you can conceptually implement your proposed architecture at the application/orchestration layer.

For example:

Application

 |

 +-- determine user ID

 |

 +-- select memory partition

         |

         +-- Users 1-100   -> Store A

         +-- Users 101-200 -> Store B

         +-- Users 201-300 -> Store C

The application could maintain a deterministic mapping such as:

User ID -> Memory Store -> Scope

and then use the selected Memory Store through the Memory Store APIs. Microsoft's low-level APIs allow the application to explicitly specify both the Memory Store and scope when updating or searching memories.

So I would answer the questions this way:

Can a single agent natively use multiple Memory Stores?
- I don't see this documented as a supported automatic configuration for a single Memory Search tool. The documented agent configuration references a particular Memory Store.
Can the application choose the Memory Store based on user ID?
- At the application/orchestration layer, yes, this is technically possible using the Memory Store APIs because your application controls the store and scope used for the operation.
Can this scale beyond 100 users?
- Multiple stores could technically partition the workload, but I would not describe this as Microsoft's officially documented scaling pattern for bypassing the 100-scope limit unless Microsoft confirms it. The current documentation simply defines the quota as 100 scopes per Memory Store.
Is there an official Microsoft sharding pattern?
- I haven't found documentation describing a supported 100 users per store → create another store sharding architecture.
What should an application requiring >100 users do?
- Given that Memory is currently in preview, I recommend confirming with Microsoft on the intended production-scale architecture rather than designing around the preview quota. Microsoft may also change these limits or introduce quota-management/scaling options as the feature develops.

One other point: Microsoft recommends using a stable identifier for each user's scope and specifically supports {{$userId}} with x-memory-user-id when using the agent Memory Search tool. This gives you per-user isolation without hard-coding individual scopes into the agent.

So the short answer is: your application can potentially orchestrate multiple Memory Stores, but I wouldn't currently consider multiple stores attached/routed automatically by a single Foundry agent a documented Microsoft scaling pattern for overcoming the 100-scope quota.

Since you're looking for a supported architecture rather than a workaround, I think confirmation from the Foundry Agent Service product team would be appropriate.

Sharing these references with you:

Microsoft - Memory in Microsoft Foundry Agent Service

Microsoft - Create and use Memory in Foundry Agent Service

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.