The problem with stateless agents<\/strong><\/h2>\n\n\n\nMost agents built on large language models are stateless by design. Each conversation starts fresh. The model gets 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 a few workarounds:<\/p>\n\n\n\n
\n- Conversation history injection<\/strong>: loading previous turns into the system prompt or message history. Works for short-term context, but it eats your token budget fast as conversations grow, and it isn’t selective. 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 gets you semantic retrieval, but you own the entire pipeline: extraction logic, embedding management, index maintenance, and 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 to unstructured or evolving information.<\/li>\n<\/ul>\n\n\n\n
Each approach works to a point, but they share the same problem: you end up spending real development effort on infrastructure that isn’t your product. You’re maintaining a memory system instead of the agent behavior your users actually care about.aintaining a memory system instead of focusing on the agent behaviour that actually matters to your users.<\/p>\n\n\n\n
How Foundry Agent Memory works<\/strong><\/h2>\n\n\n\nMemory in Foundry Agent Service is a managed, long-term memory store built into the agent runtime. Instead of building and maintaining the extraction and retrieval pipeline yourself, the service handles it.<\/p>\n\n\n\n
The process runs in 4 phases:<\/p>\n\n\n\n
\n- Extract<\/strong>: as the user interacts with the agent, the system pulls out key information: preferences, facts, and context likely to matter in future sessions. If a user mentions they work in finance and prefer bullet-point summaries, the system captures that.<\/li>\n\n\n\n
- Consolidate<\/strong>: extracted memories get merged and deduplicated. If a user said they prefer dark roast coffee and later mentions switching to light roast, an LLM resolves the conflict and updates the memory instead of storing both.<\/li>\n\n\n\n
- Retrieve<\/strong>: at the start of each new conversation, hybrid search surfaces relevant memories. Core profile facts (role, restrictions) get 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 tells the system what kind of information matters for your use case. A travel agent might prioritize airline preferences and dietary restrictions. A developer support agent might care more about 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
User profile<\/strong> memory holds durable facts about the user, like their preferences and role, plus any standing restrictions. It’s retrieved at the start of every conversation, regardless of what the user asks.<\/p>\n\n\n\nChat summary<\/strong> memory holds condensed summaries of previous conversations. It gives the agent contextual continuity: it can reference what was discussed last time without replaying the entire history.<\/p>\n\n\n\nUpdate:<\/strong> Microsoft has since added a third type, procedural memory, for reusable how-to routines the agent infers from prior interactions. It wasn’t available when this post went up.<\/p>\n\n\n\nScoping and isolation<\/strong><\/h3>\n\n\n\nMemory is partitioned by the scope <\/strong>parameter. Each scope keeps its own isolated collection of memory items. In most scenarios you’d scope memory to individual users: their Entra ID, a UUID, or {{$userId}}, which automatically extracts the tenant and object ID from the authentication header.<\/p>\n\n\n\nThis matters in enterprise scenarios, where one user’s memory absolutely cannot leak into another’s conversation. Each scope is a fully separate partition.<\/p>\n\n\n\n
Prerequisites<\/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\n- An Azure subscription with access to Microsoft Foundry<\/li>\n\n\n\n
- A Microsoft Foundry project. If you haven’t set one up, see Step 1 in my earlier post on Bing Search agents<\/li>\n\n\n\n
- The Foundry User RBAC role assigned to your identity (Microsoft renamed this from Azure AI User after this post first went up; the role ID and permissions didn’t change)<\/li>\n<\/ul>\n\n\n\n
Model Deployments<\/strong><\/h3>\n\n\n\nYou’ll need 2 model deployments in your Foundry project:<\/p>\n\n\n\n
\n- A chat model, such as gpt-4o<\/strong> or gpt-5.2<\/strong>, that handles memory extraction and consolidation<\/li>\n\n\n\n
- An embedding model, such as text-embedding-3-small<\/strong>, that powers semantic search when retrieving memories<\/li>\n<\/ul>\n\n\n\n
Deploy both from your Foundry project’s “Models + Endpoints” section, and note the deployment names.<\/p>\n\n\n\n![\"\"](\"https:\/\/codingwithramin.com\/wp-content\/uploads\/2026\/03\/image-1024x270.png\")
<\/figure>\n\n\n\nDevelopment Environment<\/strong><\/h3>\n\n\n\nYou will need:<\/p>\n\n\n\n
\n- .NET 8.0 or later<\/strong><\/li>\n\n\n\n
- Visual Studio 2022<\/strong> (or later) or VS Code<\/strong><\/li>\n<\/ul>\n\n\n\n
A note on the SDK<\/strong><\/h3>\n\n\n\nAs of March 2026, when I wrote this, the Foundry Agent Service memory feature was in public preview and the .NET SDK (Azure.AI.Projects 2.0.0-beta.1<\/strong>) hadn’t caught up. The Python SDK already had first-class support through project_client.beta.memory_stores<\/strong>, and the REST API was fully documented.<\/p>\n\n\n\nSo this post wraps the REST API in a clean .NET service class. That’s the approach I’d recommend for any preview feature anyway: it gives you full control and it’s easy to debug. You can swap in the SDK once it catches up, without changing your application code.<\/p>\n\n\n\n
Update: Microsoft has since shipped native C# support: Azure.AI.Projects and Azure.AI.Projects.Agents<\/strong>, both around version 2.1.0-beta.4 as of this update, with a MemorySearchPreviewTool and a MemoryStores client that cover most of what this post builds by hand below. If you’re starting a new project today, check the current Create and use memory<\/a> guide before you write your own HttpClient wrapper. The walkthrough below still works, and the mechanics haven’t changed, but you don’t have to build it yourself anymore.<\/p>\n\n\n\nProject setup<\/strong><\/h2>\n\n\n\nCreate a new .NET console application, or add to an existing agent project. You’ll need these packages:<\/p>\n\n\n\n
C#<\/span>
Each approach works to a point, but they share the same problem: you end up spending real development effort on infrastructure that isn’t your product. You’re maintaining a memory system instead of the agent behavior your users actually care about.aintaining a memory system instead of focusing on the agent behaviour that actually matters to your users.<\/p>\n\n\n\n
How Foundry Agent Memory works<\/strong><\/h2>\n\n\n\nMemory in Foundry Agent Service is a managed, long-term memory store built into the agent runtime. Instead of building and maintaining the extraction and retrieval pipeline yourself, the service handles it.<\/p>\n\n\n\n
The process runs in 4 phases:<\/p>\n\n\n\n
\n- Extract<\/strong>: as the user interacts with the agent, the system pulls out key information: preferences, facts, and context likely to matter in future sessions. If a user mentions they work in finance and prefer bullet-point summaries, the system captures that.<\/li>\n\n\n\n
- Consolidate<\/strong>: extracted memories get merged and deduplicated. If a user said they prefer dark roast coffee and later mentions switching to light roast, an LLM resolves the conflict and updates the memory instead of storing both.<\/li>\n\n\n\n
- Retrieve<\/strong>: at the start of each new conversation, hybrid search surfaces relevant memories. Core profile facts (role, restrictions) get 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 tells the system what kind of information matters for your use case. A travel agent might prioritize airline preferences and dietary restrictions. A developer support agent might care more about 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
User profile<\/strong> memory holds durable facts about the user, like their preferences and role, plus any standing restrictions. It’s retrieved at the start of every conversation, regardless of what the user asks.<\/p>\n\n\n\nChat summary<\/strong> memory holds condensed summaries of previous conversations. It gives the agent contextual continuity: it can reference what was discussed last time without replaying the entire history.<\/p>\n\n\n\nUpdate:<\/strong> Microsoft has since added a third type, procedural memory, for reusable how-to routines the agent infers from prior interactions. It wasn’t available when this post went up.<\/p>\n\n\n\nScoping and isolation<\/strong><\/h3>\n\n\n\nMemory is partitioned by the scope <\/strong>parameter. Each scope keeps its own isolated collection of memory items. In most scenarios you’d scope memory to individual users: their Entra ID, a UUID, or {{$userId}}, which automatically extracts the tenant and object ID from the authentication header.<\/p>\n\n\n\nThis matters in enterprise scenarios, where one user’s memory absolutely cannot leak into another’s conversation. Each scope is a fully separate partition.<\/p>\n\n\n\n
Prerequisites<\/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\n- An Azure subscription with access to Microsoft Foundry<\/li>\n\n\n\n
- A Microsoft Foundry project. If you haven’t set one up, see Step 1 in my earlier post on Bing Search agents<\/li>\n\n\n\n
- The Foundry User RBAC role assigned to your identity (Microsoft renamed this from Azure AI User after this post first went up; the role ID and permissions didn’t change)<\/li>\n<\/ul>\n\n\n\n
Model Deployments<\/strong><\/h3>\n\n\n\nYou’ll need 2 model deployments in your Foundry project:<\/p>\n\n\n\n
\n- A chat model, such as gpt-4o<\/strong> or gpt-5.2<\/strong>, that handles memory extraction and consolidation<\/li>\n\n\n\n
- An embedding model, such as text-embedding-3-small<\/strong>, that powers semantic search when retrieving memories<\/li>\n<\/ul>\n\n\n\n
Deploy both from your Foundry project’s “Models + Endpoints” section, and note the deployment names.<\/p>\n\n\n\n<\/figure>\n\n\n\nDevelopment Environment<\/strong><\/h3>\n\n\n\nYou will need:<\/p>\n\n\n\n
\n- .NET 8.0 or later<\/strong><\/li>\n\n\n\n
- Visual Studio 2022<\/strong> (or later) or VS Code<\/strong><\/li>\n<\/ul>\n\n\n\n
A note on the SDK<\/strong><\/h3>\n\n\n\nAs of March 2026, when I wrote this, the Foundry Agent Service memory feature was in public preview and the .NET SDK (Azure.AI.Projects 2.0.0-beta.1<\/strong>) hadn’t caught up. The Python SDK already had first-class support through project_client.beta.memory_stores<\/strong>, and the REST API was fully documented.<\/p>\n\n\n\nSo this post wraps the REST API in a clean .NET service class. That’s the approach I’d recommend for any preview feature anyway: it gives you full control and it’s easy to debug. You can swap in the SDK once it catches up, without changing your application code.<\/p>\n\n\n\n
Update: Microsoft has since shipped native C# support: Azure.AI.Projects and Azure.AI.Projects.Agents<\/strong>, both around version 2.1.0-beta.4 as of this update, with a MemorySearchPreviewTool and a MemoryStores client that cover most of what this post builds by hand below. If you’re starting a new project today, check the current Create and use memory<\/a> guide before you write your own HttpClient wrapper. The walkthrough below still works, and the mechanics haven’t changed, but you don’t have to build it yourself anymore.<\/p>\n\n\n\nProject setup<\/strong><\/h2>\n\n\n\nCreate a new .NET console application, or add to an existing agent project. You’ll need these packages:<\/p>\n\n\n\n
C#<\/span>
Memory types<\/strong><\/h3>\n\n\n\nThe system supports two types of memory.<\/p>\n\n\n\n
User profile<\/strong> memory holds durable facts about the user, like their preferences and role, plus any standing restrictions. It’s retrieved at the start of every conversation, regardless of what the user asks.<\/p>\n\n\n\nChat summary<\/strong> memory holds condensed summaries of previous conversations. It gives the agent contextual continuity: it can reference what was discussed last time without replaying the entire history.<\/p>\n\n\n\nUpdate:<\/strong> Microsoft has since added a third type, procedural memory, for reusable how-to routines the agent infers from prior interactions. It wasn’t available when this post went up.<\/p>\n\n\n\nScoping and isolation<\/strong><\/h3>\n\n\n\nMemory is partitioned by the scope <\/strong>parameter. Each scope keeps its own isolated collection of memory items. In most scenarios you’d scope memory to individual users: their Entra ID, a UUID, or {{$userId}}, which automatically extracts the tenant and object ID from the authentication header.<\/p>\n\n\n\nThis matters in enterprise scenarios, where one user’s memory absolutely cannot leak into another’s conversation. Each scope is a fully separate partition.<\/p>\n\n\n\n
Prerequisites<\/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\n- An Azure subscription with access to Microsoft Foundry<\/li>\n\n\n\n
- A Microsoft Foundry project. If you haven’t set one up, see Step 1 in my earlier post on Bing Search agents<\/li>\n\n\n\n
- The Foundry User RBAC role assigned to your identity (Microsoft renamed this from Azure AI User after this post first went up; the role ID and permissions didn’t change)<\/li>\n<\/ul>\n\n\n\n
Model Deployments<\/strong><\/h3>\n\n\n\nYou’ll need 2 model deployments in your Foundry project:<\/p>\n\n\n\n
\n- A chat model, such as gpt-4o<\/strong> or gpt-5.2<\/strong>, that handles memory extraction and consolidation<\/li>\n\n\n\n
- An embedding model, such as text-embedding-3-small<\/strong>, that powers semantic search when retrieving memories<\/li>\n<\/ul>\n\n\n\n
Deploy both from your Foundry project’s “Models + Endpoints” section, and note the deployment names.<\/p>\n\n\n\n<\/figure>\n\n\n\nDevelopment Environment<\/strong><\/h3>\n\n\n\nYou will need:<\/p>\n\n\n\n
\n- .NET 8.0 or later<\/strong><\/li>\n\n\n\n
- Visual Studio 2022<\/strong> (or later) or VS Code<\/strong><\/li>\n<\/ul>\n\n\n\n
A note on the SDK<\/strong><\/h3>\n\n\n\nAs of March 2026, when I wrote this, the Foundry Agent Service memory feature was in public preview and the .NET SDK (Azure.AI.Projects 2.0.0-beta.1<\/strong>) hadn’t caught up. The Python SDK already had first-class support through project_client.beta.memory_stores<\/strong>, and the REST API was fully documented.<\/p>\n\n\n\nSo this post wraps the REST API in a clean .NET service class. That’s the approach I’d recommend for any preview feature anyway: it gives you full control and it’s easy to debug. You can swap in the SDK once it catches up, without changing your application code.<\/p>\n\n\n\n
Update: Microsoft has since shipped native C# support: Azure.AI.Projects and Azure.AI.Projects.Agents<\/strong>, both around version 2.1.0-beta.4 as of this update, with a MemorySearchPreviewTool and a MemoryStores client that cover most of what this post builds by hand below. If you’re starting a new project today, check the current Create and use memory<\/a> guide before you write your own HttpClient wrapper. The walkthrough below still works, and the mechanics haven’t changed, but you don’t have to build it yourself anymore.<\/p>\n\n\n\nProject setup<\/strong><\/h2>\n\n\n\nCreate a new .NET console application, or add to an existing agent project. You’ll need these packages:<\/p>\n\n\n\n
C#<\/span>
Chat summary<\/strong> memory holds condensed summaries of previous conversations. It gives the agent contextual continuity: it can reference what was discussed last time without replaying the entire history.<\/p>\n\n\n\n Update:<\/strong> Microsoft has since added a third type, procedural memory, for reusable how-to routines the agent infers from prior interactions. It wasn’t available when this post went up.<\/p>\n\n\n\n Memory is partitioned by the scope <\/strong>parameter. Each scope keeps its own isolated collection of memory items. In most scenarios you’d scope memory to individual users: their Entra ID, a UUID, or {{$userId}}, which automatically extracts the tenant and object ID from the authentication header.<\/p>\n\n\n\n This matters in enterprise scenarios, where one user’s memory absolutely cannot leak into another’s conversation. Each scope is a fully separate partition.<\/p>\n\n\n\n Before we start coding, make sure you have the following in place:<\/p>\n\n\n\n You’ll need 2 model deployments in your Foundry project:<\/p>\n\n\n\n Deploy both from your Foundry project’s “Models + Endpoints” section, and note the deployment names.<\/p>\n\n\n\n You will need:<\/p>\n\n\n\n As of March 2026, when I wrote this, the Foundry Agent Service memory feature was in public preview and the .NET SDK (Azure.AI.Projects 2.0.0-beta.1<\/strong>) hadn’t caught up. The Python SDK already had first-class support through project_client.beta.memory_stores<\/strong>, and the REST API was fully documented.<\/p>\n\n\n\n So this post wraps the REST API in a clean .NET service class. That’s the approach I’d recommend for any preview feature anyway: it gives you full control and it’s easy to debug. You can swap in the SDK once it catches up, without changing your application code.<\/p>\n\n\n\n Update: Microsoft has since shipped native C# support: Azure.AI.Projects and Azure.AI.Projects.Agents<\/strong>, both around version 2.1.0-beta.4 as of this update, with a MemorySearchPreviewTool and a MemoryStores client that cover most of what this post builds by hand below. If you’re starting a new project today, check the current Create and use memory<\/a> guide before you write your own HttpClient wrapper. The walkthrough below still works, and the mechanics haven’t changed, but you don’t have to build it yourself anymore.<\/p>\n\n\n\n Create a new .NET console application, or add to an existing agent project. You’ll need these packages:<\/p>\n\n\n\nScoping and isolation<\/strong><\/h3>\n\n\n\n
Prerequisites<\/strong><\/h2>\n\n\n\n
Azure Requirements<\/strong><\/h3>\n\n\n\n
\n
Model Deployments<\/strong><\/h3>\n\n\n\n
\n
<\/figure>\n\n\n\nDevelopment Environment<\/strong><\/h3>\n\n\n\n
\n
A note on the SDK<\/strong><\/h3>\n\n\n\n
Project setup<\/strong><\/h2>\n\n\n\n