Azure OpenAI Client with Memory (mem0)

on

 

https://www.pexels.com/photo/pictures-hanging-on-strings-attached-to-trees-in-a-garden-15928649/
https://www.pexels.com/photo/pictures-hanging-on-strings-attached-to-trees-in-a-garden-15928649/

In our previous blog post, we introduced the Microsoft Foundry Memory Store. In this post, we will demonstrate how to use mem0 with the Azure OpenAI Client to create a memory-aware agent. This is a simple example that shows how to store and retrieve memories using mem0. Along the way, we compare mem0 with the Microsoft Foundry Memory Store.

git: https://github.com/dennisseah/azure-mem0

Setting up the Environment

Mem0 allows you to use different LLM and embedding models. You can configure the model and deployment name in the environment variables. For example, you can set the following environment variables: 

LLM_AZURE_DEPLOYMENT=
LLM_AZURE_ENDPOINT=
LLM_AZURE_API_VERSION=

EMBEDDING_AZURE_DEPLOYMENT=
EMBEDDING_AZURE_ENDPOINT=
EMBEDDING_AZURE_API_VERSION=

Mem0 supports a wide range of LLMs and embedding models, with native, modular integrations for multiple providers. By default, it uses OpenAI’s gpt-4o-mini for the LLM and text-embedding-3-small for embeddings, but these can be easily swapped out via configuration. For a full breakdown of how to swap and configure these models for your specific project, you can refer to the official Mem0 LLM Documentation and Mem0 Embedding Documentation.

On the other hand, the Microsoft Foundry Memory Store also lets you choose its models: when you create a store, you nominate a chat model deployment (for summarization and extraction) and an embedding model deployment (for semantic search), such as gpt-5.2 and text-embedding-3-small. The key difference is where those models live. They must be deployments within your Azure AI Foundry project, which includes Azure OpenAI as well as other catalog models such as Mistral and Llama, rather than any external provider. So while the agent's own LLM and the store's models are configurable, the Memory Store is scoped to Foundry-hosted deployments, whereas mem0 is fully provider-agnostic and can target Azure, OpenAI, Anthropic, Google, or local models.

For teams that want to reach beyond the Foundry catalog, this is a meaningful constraint: every model the store uses must first be deployed in your Foundry project. Adding a new provider means provisioning another deployment rather than simply pointing at an external endpoint. With mem0, you can switch between providers and models through configuration alone, with no deployment step.

Simple Example

Following is a simple example of how to use mem0 with the Azure OpenAI Client to create a memory-aware agent. The example uses the mem0ai package to store and retrieve memories. The agent remembers that the user likes coffee and uses that in future interactions.

  1. Send a message to the agent: "I like to drink coffee in the morning."
    1. Try to retrieve any memory of the user's liking of coffee.
    2. No memory is found because this is the first interaction, so the agent responds with a generic message.
    3. Store the user message and the agent's response in mem0.
  2. Send another message to the agent: "What do I like to drink?"
    1. Try to retrieve any memory of the user's liking of coffee.
    2. The memory is found, so the agent responds with a message that acknowledges the user's liking of coffee.
    3. Store the user message and the agent's response in mem0.
Finally, dump the memories stored in mem0 for inspection. You should see the memory of the user's liking of coffee.

Retrieval Model

In the Microsoft Foundry Memory Store, memory is partitioned by a single scope string that you supply on every read and write. In mem0, memory is partitioned by structured identifiers: user_id, agent_id, and run_id. These built-in dimensions make multi-agent scenarios straightforward. If several agents interact with the same user, agent_id keeps each agent's memories separate, so they can remember different things about that user without interfering with one another.

You can approximate the same isolation in the Foundry Memory Store by encoding those dimensions into the scope string yourself (for example, user-123/agent-x), but mem0 models them as first-class fields, which is more explicit and less error-prone. Foundry matches a scope exactly, so there is no prefix or wildcard lookup such as agent-x-*; you must read and write with the same scope string. In mem0, user_id, agent_id, and run_id accept arbitrary strings and are stored as separate fields that you can filter on directly.

Vector Store

In our simple example, we used the default vector store provided by mem0, which is Qdrant running in embedded mode and persisting to a local path on disk. mem0 also supports many other vector stores, including Pinecone, Weaviate, Milvus, Azure AI Search, and pgvector. You configure the vector store in the mem0 configuration, alongside the LLM and embedder settings.

Conclusion

In this post, we demonstrated how to pair mem0 with the Azure OpenAI Client to build a memory-aware agent, and we compared mem0 with the Microsoft Foundry Memory Store. mem0 offers a flexible, provider-agnostic way to store and retrieve memories, and it models scope as structured identifiers, which is convenient in multi-agent scenarios. The Foundry Memory Store, by contrast, is a managed service integrated with your Foundry project: it handles summarization, embedding, and retrieval for you, at the cost of keeping models and infrastructure within Foundry. Which one fits best depends on whether you value mem0's portability or the Foundry Memory Store's managed, integrated experience.

Demo







Comments

Post a Comment