The Problem with Stateless Agents<\/strong><\/h2>\n\n\n\nMost agents built on top of large language models are stateless by design. Each conversation starts fresh. The model receives a prompt, generates a response, and moves on. There’s no built-in mechanism to carry information from one session to the next.<\/p>\n\n\n\n
Developers have tried various approaches to work around this:<\/p>\n\n\n\n
\n- Conversation History Injection<\/strong>: Loading previous conversation turns into the system prompt or message history. This works for short-term context but quickly eats into your token budget as conversations grow. It’s also not selective \u2014 you’re injecting everything, not just what’s relevant.<\/li>\n\n\n\n
- Custom Vector Stores<\/strong>: Extracting key information from conversations, embedding it, and storing it in something like Azure AI Search or a dedicated vector database. This gives you semantic retrieval, but you’re now responsible for the entire pipeline \u2014 extraction logic, embedding management, index maintenance, conflict resolution when facts change.<\/li>\n\n\n\n
- Database-Backed State<\/strong>: Storing structured user preferences in a traditional database and injecting them into prompts. Simple and effective for known attributes, but it doesn’t scale well to unstructured or evolving information.<\/li>\n<\/ul>\n\n\n\n
Each of these approaches works to varying degrees, but they all share a common problem: you’re spending a significant amount of development effort on infrastructure that isn’t your core product. You’re building and maintaining a memory system instead of focusing on the agent behaviour that actually matters to your users.<\/p>\n\n\n\n
What Foundry Agent Memory Actually Does<\/strong><\/h2>\n\n\n\nMemory in Foundry Agent Service is a managed, long-term memory store that’s natively integrated with the agent runtime. Instead of you building and maintaining the extraction and retrieval pipeline, the service handles it automatically.<\/p>\n\n\n\n
The process works in four phases:<\/p>\n\n\n\n
\n- Extract<\/strong>: As the user interacts with the agent, the system identifies and pulls out key information \u2014 preferences, facts, context that’s likely to be relevant in future sessions. For instance, if a user mentions they work in the finance department and prefer bullet-point summaries, the system captures that.<\/li>\n\n\n\n
- Consolidate<\/strong>: Extracted memories are merged and deduplicated. If the user previously said they prefer dark roast coffee and later mentions they’ve switched to light roast, the system uses an LLM to resolve the conflict and update the memory rather than storing both.<\/li>\n\n\n\n
- Retrieve<\/strong>: At the start of each new conversation, the system uses hybrid search to surface relevant memories. Core profile facts (like dietary restrictions or role) are injected immediately. Contextual memories are retrieved per turn based on the latest messages.<\/li>\n\n\n\n
- Customize<\/strong>: The user_profile_details<\/strong> parameter lets you tell the system what kinds of information matter for your specific use case. A travel agent might prioritize airline preferences and dietary restrictions. A developer support agent might focus on programming languages and framework versions.<\/li>\n<\/ul>\n\n\n\n
Memory Types<\/strong><\/h3>\n\n\n\nThe system supports two types of memory:<\/p>\n\n\n\n
\n- User Profile<\/strong>: Static facts about the user that remain relevant across sessions \u2014 preferences, roles, restrictions. These are retrieved at the beginning of every conversation regardless of what the user asks.<\/li>\n\n\n\n
- Chat Summary<\/strong>: Condensed summaries of previous conversations. These provide contextual continuity \u2014 the agent can reference what was discussed last time without needing to replay the entire conversation history.<\/li>\n<\/ul>\n\n\n\n
Scoping and Isolation<\/strong><\/h3>\n\n\n\nMemory is partitioned using the scope<\/strong> parameter. Each scope maintains an isolated collection of memory items. In most scenarios, you’d scope memory to individual users \u2014 using their Entra ID, a UUID, or {{$userId}}<\/strong> which automatically extracts the tenant and object ID from the authentication header.<\/p>\n\n\n\nThis is important for enterprise scenarios where you absolutely cannot have one user’s memory leaking into another user’s conversations. Each scope is a completely separate partition.<\/p>\n\n\n\n
Prerequisites and Setup<\/strong><\/h2>\n\n\n\nBefore we start coding, make sure you have the following in place:<\/p>\n\n\n\n
Azure Requirements<\/strong><\/h3>\n\n\n\n
Each of these approaches works to varying degrees, but they all share a common problem: you’re spending a significant amount of development effort on infrastructure that isn’t your core product. You’re building and maintaining a memory system instead of focusing on the agent behaviour that actually matters to your users.<\/p>\n\n\n\n
What Foundry Agent Memory Actually Does<\/strong><\/h2>\n\n\n\nMemory in Foundry Agent Service is a managed, long-term memory store that’s natively integrated with the agent runtime. Instead of you building and maintaining the extraction and retrieval pipeline, the service handles it automatically.<\/p>\n\n\n\n
The process works in four phases:<\/p>\n\n\n\n
\n- Extract<\/strong>: As the user interacts with the agent, the system identifies and pulls out key information \u2014 preferences, facts, context that’s likely to be relevant in future sessions. For instance, if a user mentions they work in the finance department and prefer bullet-point summaries, the system captures that.<\/li>\n\n\n\n
- Consolidate<\/strong>: Extracted memories are merged and deduplicated. If the user previously said they prefer dark roast coffee and later mentions they’ve switched to light roast, the system uses an LLM to resolve the conflict and update the memory rather than storing both.<\/li>\n\n\n\n
- Retrieve<\/strong>: At the start of each new conversation, the system uses hybrid search to surface relevant memories. Core profile facts (like dietary restrictions or role) are injected immediately. Contextual memories are retrieved per turn based on the latest messages.<\/li>\n\n\n\n
- Customize<\/strong>: The user_profile_details<\/strong> parameter lets you tell the system what kinds of information matter for your specific use case. A travel agent might prioritize airline preferences and dietary restrictions. A developer support agent might focus on programming languages and framework versions.<\/li>\n<\/ul>\n\n\n\n
Memory Types<\/strong><\/h3>\n\n\n\nThe system supports two types of memory:<\/p>\n\n\n\n
\n- User Profile<\/strong>: Static facts about the user that remain relevant across sessions \u2014 preferences, roles, restrictions. These are retrieved at the beginning of every conversation regardless of what the user asks.<\/li>\n\n\n\n
- Chat Summary<\/strong>: Condensed summaries of previous conversations. These provide contextual continuity \u2014 the agent can reference what was discussed last time without needing to replay the entire conversation history.<\/li>\n<\/ul>\n\n\n\n
Scoping and Isolation<\/strong><\/h3>\n\n\n\nMemory is partitioned using the scope<\/strong> parameter. Each scope maintains an isolated collection of memory items. In most scenarios, you’d scope memory to individual users \u2014 using their Entra ID, a UUID, or {{$userId}}<\/strong> which automatically extracts the tenant and object ID from the authentication header.<\/p>\n\n\n\nThis is important for enterprise scenarios where you absolutely cannot have one user’s memory leaking into another user’s conversations. Each scope is a completely separate partition.<\/p>\n\n\n\n
Prerequisites and Setup<\/strong><\/h2>\n\n\n\nBefore we start coding, make sure you have the following in place:<\/p>\n\n\n\n
Azure Requirements<\/strong><\/h3>\n\n\n\n
Memory Types<\/strong><\/h3>\n\n\n\nThe system supports two types of memory:<\/p>\n\n\n\n
\n- User Profile<\/strong>: Static facts about the user that remain relevant across sessions \u2014 preferences, roles, restrictions. These are retrieved at the beginning of every conversation regardless of what the user asks.<\/li>\n\n\n\n
- Chat Summary<\/strong>: Condensed summaries of previous conversations. These provide contextual continuity \u2014 the agent can reference what was discussed last time without needing to replay the entire conversation history.<\/li>\n<\/ul>\n\n\n\n
Scoping and Isolation<\/strong><\/h3>\n\n\n\nMemory is partitioned using the scope<\/strong> parameter. Each scope maintains an isolated collection of memory items. In most scenarios, you’d scope memory to individual users \u2014 using their Entra ID, a UUID, or {{$userId}}<\/strong> which automatically extracts the tenant and object ID from the authentication header.<\/p>\n\n\n\nThis is important for enterprise scenarios where you absolutely cannot have one user’s memory leaking into another user’s conversations. Each scope is a completely separate partition.<\/p>\n\n\n\n
Prerequisites and Setup<\/strong><\/h2>\n\n\n\nBefore we start coding, make sure you have the following in place:<\/p>\n\n\n\n
Azure Requirements<\/strong><\/h3>\n\n\n\n
Scoping and Isolation<\/strong><\/h3>\n\n\n\nMemory is partitioned using the scope<\/strong> parameter. Each scope maintains an isolated collection of memory items. In most scenarios, you’d scope memory to individual users \u2014 using their Entra ID, a UUID, or {{$userId}}<\/strong> which automatically extracts the tenant and object ID from the authentication header.<\/p>\n\n\n\nThis is important for enterprise scenarios where you absolutely cannot have one user’s memory leaking into another user’s conversations. Each scope is a completely separate partition.<\/p>\n\n\n\n
Prerequisites and Setup<\/strong><\/h2>\n\n\n\nBefore we start coding, make sure you have the following in place:<\/p>\n\n\n\n
Azure Requirements<\/strong><\/h3>\n\n\n\n
This is important for enterprise scenarios where you absolutely cannot have one user’s memory leaking into another user’s conversations. Each scope is a completely separate partition.<\/p>\n\n\n\n
![\"\"](\"https:\/\/codingwithramin.com\/wp-content\/uploads\/2026\/03\/image-1024x270.png\")
<\/figure>\n\n\n\n