Skip to main contentSkip to footer
ExamplescriptbeginnerRunnablememory-lab

Mem0 Oss Quickstart

Runnable example (beginner) for script using mem0, mem0ai.

Key Facts

Level
beginner
Runtime
Python • OpenAI API
Pattern
Memory-aware assistance with legible context
Interaction
Live sandbox • Script
Updated
14 March 2026

Navigate this example

Linked principles

Ensure that background work remains perceptibleAlign feedback with the user’s level of attentionEstablish trust through inspectability

High-level flow

How this example moves from input to execution and reviewable output
Mem0 Oss Quickstart -> User request -> System execution -> Reviewable output -> Ensure that background work… -> Align feedback with the…

Start

Mem0 Oss Quickstart

Checkpoint

User request

Outcome

System execution

Why this page exists

This example is shown as both real source code and a product-facing interaction pattern so learners can connect implementation, UX, and doctrine without leaving the library.

Visual flowReal sourceSandbox or walkthroughMCP access
How should this example be used in the platform?

Use the sandbox to understand the experience pattern first, then inspect the source to see how the product boundary, model boundary, and doctrine boundary are actually implemented.

UX pattern: Memory-aware assistance with legible context
Ensure that background work remains perceptible
Align feedback with the user’s level of attention
Establish trust through inspectability
Source references
Library entry
knowledge-mem0-02-mem0-oss-quickstart
Source path
content/example-library/sources/knowledge/mem0/02-mem0-oss-quickstart.py
Libraries
mem0, mem0ai, openai, python-dotenv
Runtime requirements
OPENAI_API_KEY
Related principles
Ensure that background work remains perceptible, Align feedback with the user’s level of attention, Establish trust through inspectability

02-mem0-oss-quickstart.py

python
from mem0 import Memory
from dotenv import load_dotenv

load_dotenv(".env")
m = Memory()  # Requires OpenAI API key

# --------------------------------------------------------------
# Message sequence
# --------------------------------------------------------------

messages = [
    {
        "role": "user",
        "content": "I'm planning to watch a movie tonight. Any recommendations?",
    },
    {
        "role": "assistant",
        "content": "How about a thriller movies? They can be quite engaging.",
    },
    {
        "role": "user",
        "content": "I'm not a big fan of thriller movies but I love sci-fi movies.",
    },
    {
        "role": "assistant",
        "content": "Got it! I'll avoid thriller recommendations and suggest sci-fi movies in the future.",
    },
]

# --------------------------------------------------------------
# Store inferred memories (default behavior)
# --------------------------------------------------------------

result = m.add(
    messages, user_id="default_user", metadata={"category": "movie_recommendations"}
)

# --------------------------------------------------------------
# Get all memories
# --------------------------------------------------------------

all_memories = m.get_all(user_id="default_user")

# --------------------------------------------------------------
# Search for related memories
# --------------------------------------------------------------

related_memories = m.search(query="What do you know about me?", user_id="default_user")

print(related_memories)
What should the learner inspect in the code?

Look for the exact place where system scope is bounded: schema definitions, prompt framing, runtime configuration, and the call site that turns user intent into a concrete model or workflow action.

Look for output contracts and validation
Look for the exact execution call
Look for what the product could expose to the user
How does the sandbox relate to the source?

The sandbox should make the UX legible: what the user sees, what the system is deciding, and how the result becomes reviewable. The source then shows how that behavior is actually implemented.

Enter a message or load a memory scenario.
Run the context recall step.
Inspect both the recalled memory and the personalized reply.
SandboxMemory-aware assistance with legible context
Memory lab

This experience makes it clear what the system remembers, what it retrieves, and how that context changes the reply.

UX explanation

Memory examples are only trustworthy when the user can understand which information was recalled and why it changes the response.

AI design explanation

Memory is not just persistence. It is a product choice about what to store, what to recall, and how to make the effect of context inspectable.

Interaction walkthrough

  1. 1Enter a message or load a memory scenario.
  2. 2Run the context recall step.
  3. 3Inspect both the recalled memory and the personalized reply.

Principles in focus

Ensure that background work remains perceptibleAlign feedback with the user’s level of attentionEstablish trust through inspectability

Message

Recalled memoryNew memory

Recalled context

The recalled context appears here.

Memory to store

The suggested memory write appears here.

Visible reply

The personalized reply appears here.

Used in courses and paths

This example currently stands on its own in the library, but it still connects to the principle system and the broader example family.

Related implementation patterns

Related principles

Runtime architecture

Use this example in your agents

This example is also available through the blueprint’s agent-ready layer. Use the For agents page for the public MCP, deterministic exports, and Claude/Cursor setup.

Define triggers, context, and boundaries before increasing autonomy
Make control, observability, and recovery explicit in the runtime
Choose the right operational patterns before delegating to workflows
Open For agents