[docs] platform core concept revamp and overview update (#3664)
This commit is contained in:
Parth Sharma
@@ -5,43 +5,52 @@ icon: "plus"
|
||||
iconType: "solid"
|
||||
---
|
||||
|
||||
# How Mem0 Adds Memory
|
||||
|
||||
## Overview
|
||||
Adding memory is how Mem0 captures useful details from a conversation so your agents can reuse them later. Think of it as saving the important sentences from a chat transcript into a structured notebook your agent can search.
|
||||
|
||||
The `add` operation stores memory into Mem0. Whether you're working with a chatbot, a voice assistant, or a multi-agent system, this is the entry point to create long-term memory.
|
||||
<Info>
|
||||
**Why it matters**
|
||||
- Preserves user preferences, goals, and feedback across sessions.
|
||||
- Powers personalization and decision-making in downstream conversations.
|
||||
- Keeps context consistent between managed Platform and OSS deployments.
|
||||
</Info>
|
||||
|
||||
Memories typically come from a **user-assistant interaction** and Mem0 handles the extraction, transformation, and storage for you.
|
||||
## Key terms
|
||||
|
||||
Mem0 offers two implementation flows:
|
||||
- **Messages** – The ordered list of user/assistant turns you send to `add`.
|
||||
- **Infer** – Controls whether Mem0 extracts structured memories (`infer=True`, default) or stores raw messages.
|
||||
- **Metadata** – Optional filters (e.g., `{"category": "movie_recommendations"}`) that improve retrieval later.
|
||||
- **User / Session identifiers** – `user_id`, `session_id`, or `run_id` that scope the memory for future searches.
|
||||
|
||||
- **Mem0 Platform** (Managed, scalable, with dashboard + API)
|
||||
- **Mem0 Open Source** (Lightweight, fully local, flexible SDKs)
|
||||
## How does it work?
|
||||
|
||||
Each supports the same core memory operations, but with slightly different setup.
|
||||
Mem0 offers two flows:
|
||||
|
||||
- **Mem0 Platform** – Fully managed API with dashboard, scaling, and graph features.
|
||||
- **Mem0 Open Source** – Local SDK that you run in your own environment.
|
||||
|
||||
## Architecture
|
||||
Both flows take the same payload and pass it through the same pipeline.
|
||||
|
||||
<Frame caption="Architecture diagram illustrating the process of adding memories.">
|
||||
<img src="../../images/add_architecture.png" />
|
||||
</Frame>
|
||||
|
||||
When you call `add`, Mem0 performs the following steps under the hood:
|
||||
<Steps>
|
||||
<Step title="Information extraction">
|
||||
Mem0 sends the messages through an LLM that pulls out key facts, decisions, or preferences to remember.
|
||||
</Step>
|
||||
<Step title="Conflict resolution">
|
||||
Existing memories are checked for duplicates or contradictions so the latest truth wins.
|
||||
</Step>
|
||||
<Step title="Storage">
|
||||
The resulting memories land in managed vector storage (and optional graph storage) so future searches return them quickly.
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
1. **Information Extraction**
|
||||
The input messages are passed through an LLM that extracts key facts, decisions, preferences, or events worth remembering.
|
||||
You trigger this pipeline with a single `add` call—no manual orchestration needed.
|
||||
|
||||
2. **Conflict Resolution**
|
||||
Mem0 compares the new memory against existing ones to detect duplication or contradiction and handles updates accordingly.
|
||||
|
||||
3. **Memory Storage**
|
||||
The result is stored in a vector database (for semantic search) and optionally in a graph structure (for relationship mapping).
|
||||
|
||||
You don't need to handle any of this manually - Mem0 takes care of it with a single API call or SDK method.
|
||||
|
||||
---
|
||||
|
||||
## Example: Mem0 Platform
|
||||
## Add with Mem0 Platform
|
||||
|
||||
<CodeGroup>
|
||||
```python Python
|
||||
@@ -79,9 +88,11 @@ await client.add({
|
||||
```
|
||||
</CodeGroup>
|
||||
|
||||
---
|
||||
<Info icon="check">
|
||||
Expect a `memory_id` (or list of IDs) in the response. Check the Mem0 dashboard to confirm the new entry under the correct user.
|
||||
</Info>
|
||||
|
||||
## Example: Mem0 Open Source
|
||||
## Add with Mem0 Open Source
|
||||
|
||||
<CodeGroup>
|
||||
```python Python
|
||||
@@ -125,7 +136,9 @@ const result = memory.add(messages, {
|
||||
```
|
||||
</CodeGroup>
|
||||
|
||||
---
|
||||
<Tip>
|
||||
Use `infer=False` only when you need to store raw transcripts. Most workflows benefit from Mem0 extracting structured memories automatically.
|
||||
</Tip>
|
||||
|
||||
## When Should You Add Memory?
|
||||
|
||||
@@ -145,9 +158,38 @@ Storing this context allows the agent to reason better in future interactions.
|
||||
For full list of supported fields, required formats, and advanced options, see the
|
||||
[Add Memory API Reference](/api-reference/memory/add-memories).
|
||||
|
||||
---
|
||||
## Managed vs OSS differences
|
||||
|
||||
## Need help?
|
||||
If you have any questions, please feel free to reach out to us using one of the following methods:
|
||||
| Capability | Mem0 Platform | Mem0 OSS |
|
||||
| --- | --- | --- |
|
||||
| Conflict resolution | Automatic with dashboard visibility | SDK handles merges locally; you control storage |
|
||||
| Graph writes | Toggle per request (`enable_graph=True`) | Requires configuring a graph provider |
|
||||
| Rate limits | Managed quotas per workspace | Limited by your hardware and provider APIs |
|
||||
| Dashboard visibility | Yes — inspect memories visually | Inspect via CLI, logs, or custom UI |
|
||||
|
||||
<Snippet file="get-help.mdx"/>
|
||||
## Put it into practice
|
||||
|
||||
- Review the <Link href="/platform/advanced-memory-operations">Advanced Memory Operations</Link> guide to layer metadata, rerankers, and graph toggles.
|
||||
- Explore the <Link href="/api-reference/memory/add-memories">Add Memories API reference</Link> for every request/response field.
|
||||
|
||||
## See it live
|
||||
|
||||
- <Link href="/examples/customer-support-agent">Customer Support Agent</Link> shows add + search powering a support flow.
|
||||
- <Link href="/examples/personal-ai-tutor">Personal AI Tutor</Link> uses add to personalize lesson plans.
|
||||
|
||||
{/* DEBUG: verify CTA targets */}
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card
|
||||
title="Explore Search Concepts"
|
||||
description="See how stored memories feed retrieval in the Search guide."
|
||||
icon="search"
|
||||
href="/core-concepts/memory-operations/search"
|
||||
/>
|
||||
<Card
|
||||
title="Build a Support Agent"
|
||||
description="Follow the cookbook to apply add/search/update in production."
|
||||
icon="rocket"
|
||||
href="/examples/customer-support-agent"
|
||||
/>
|
||||
</CardGroup>
|
||||
|
||||
@@ -5,27 +5,39 @@ icon: "trash"
|
||||
iconType: "solid"
|
||||
---
|
||||
|
||||
## Overview
|
||||
# Remove Memories Safely
|
||||
|
||||
Memories can become outdated, irrelevant, or need to be removed for privacy or compliance reasons. Mem0 offers flexible ways to delete memory:
|
||||
Deleting memories is how you honor compliance requests, undo bad data, or clean up expired sessions. Mem0 lets you delete a specific memory, a list of IDs, or everything that matches a filter.
|
||||
|
||||
1. **Delete a Single Memory**: Using a specific memory ID
|
||||
2. **Batch Delete**: Delete multiple known memory IDs (up to 1000)
|
||||
3. **Filtered Delete**: Delete memories matching a filter (e.g., `user_id`, `metadata`, `run_id`)
|
||||
<Info>
|
||||
**Why it matters**
|
||||
- Satisfies user erasure (GDPR/CCPA) without touching the rest of your data.
|
||||
- Keeps knowledge bases accurate by removing stale or incorrect facts.
|
||||
- Works for both the managed Platform API and the OSS SDK.
|
||||
</Info>
|
||||
|
||||
This page walks through code examples for each method.
|
||||
## Key terms
|
||||
|
||||
- **memory_id** – Unique ID returned by `add`/`search` identifying the record to delete.
|
||||
- **batch_delete** – API call that removes up to 1000 memories in one request.
|
||||
- **delete_all** – Filter-based deletion by user, agent, run, or metadata.
|
||||
- **immutable** – Flagged memories that cannot be updated; delete + re-add instead.
|
||||
|
||||
## Use Cases
|
||||
## How the delete flow works
|
||||
|
||||
- Forget a user’s past preferences by request
|
||||
- Remove outdated or incorrect memory entries
|
||||
- Clean up memory after session expiration
|
||||
- Comply with data deletion requests (e.g., GDPR)
|
||||
<Steps>
|
||||
<Step title="Choose the scope">
|
||||
Decide whether you’re removing a single memory, a list, or everything that matches a filter.
|
||||
</Step>
|
||||
<Step title="Submit the delete call">
|
||||
Call `delete`, `batch_delete`, or `delete_all` with the required IDs or filters.
|
||||
</Step>
|
||||
<Step title="Verify">
|
||||
Confirm the response message, then re-run `search` or check the dashboard/logs to ensure the memory is gone.
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
---
|
||||
|
||||
## 1. Delete a Single Memory by ID
|
||||
## Delete a single memory (Platform)
|
||||
|
||||
<CodeGroup>
|
||||
```python Python
|
||||
@@ -48,9 +60,11 @@ client.delete("your_memory_id")
|
||||
```
|
||||
</CodeGroup>
|
||||
|
||||
---
|
||||
<Info icon="check">
|
||||
You’ll receive a confirmation payload. The dashboard reflects the removal within seconds.
|
||||
</Info>
|
||||
|
||||
## 2. Batch Delete Multiple Memories
|
||||
## Batch delete multiple memories (Platform)
|
||||
|
||||
<CodeGroup>
|
||||
```python Python
|
||||
@@ -83,9 +97,7 @@ client.batchDelete(deleteMemories)
|
||||
```
|
||||
</CodeGroup>
|
||||
|
||||
---
|
||||
|
||||
## 3. Delete Memories by Filter (e.g., user_id)
|
||||
## Delete memories by filter (Platform)
|
||||
|
||||
<CodeGroup>
|
||||
```python Python
|
||||
@@ -114,27 +126,65 @@ You can also filter by other parameters such as:
|
||||
- `run_id`
|
||||
- `metadata` (as JSON string)
|
||||
|
||||
---
|
||||
<Warning>
|
||||
`delete_all` requires at least one filter (user, agent, run, or metadata). Calling it with no filters raises an error to prevent accidental data loss.
|
||||
</Warning>
|
||||
|
||||
## Key Differences
|
||||
## Delete with Mem0 OSS
|
||||
|
||||
| Method | Use When | IDs Needed | Filters |
|
||||
|----------------------|-------------------------------------------|------------|----------|
|
||||
| `delete(memory_id)` | You know exactly which memory to remove | ✔ | ✘ |
|
||||
| `batch_delete([...])`| You have a known list of memory IDs | ✔ | ✘ |
|
||||
| `delete_all(...)` | You want to delete by user/agent/run/etc | ✘ | ✔ |
|
||||
<CodeGroup>
|
||||
```python Python
|
||||
from mem0 import Memory
|
||||
|
||||
memory = Memory()
|
||||
|
||||
### More Details
|
||||
memory.delete(memory_id="mem_123")
|
||||
memory.delete_all(user_id="alice")
|
||||
```
|
||||
</CodeGroup>
|
||||
|
||||
For request/response schema and additional filtering options, see:
|
||||
- [Delete Memory API Reference](/api-reference/memory/delete-memory)
|
||||
- [Batch Delete API Reference](/api-reference/memory/batch-delete)
|
||||
- [Delete Memories by Filter Reference](/api-reference/memory/delete-memories)
|
||||
<Note>
|
||||
The OSS JavaScript SDK does not yet expose deletion helpers—use the REST API or Python SDK when self-hosting.
|
||||
</Note>
|
||||
|
||||
You’ve now seen how to add, search, update, and delete memories in Mem0.
|
||||
## Use cases recap
|
||||
|
||||
## Need help?
|
||||
If you have any questions, please feel free to reach out to us using one of the following methods:
|
||||
- Forget a user’s preferences at their request.
|
||||
- Remove outdated or incorrect facts before they spread.
|
||||
- Clean up memories after session expiration or retention deadlines.
|
||||
- Comply with privacy legislation (GDPR, CCPA) and internal policies.
|
||||
|
||||
<Snippet file="get-help.mdx"/>
|
||||
## Method comparison
|
||||
|
||||
| Method | Use when | IDs required | Filters |
|
||||
| --- | --- | --- | --- |
|
||||
| `delete(memory_id)` | You know the exact record | ✔️ | ✖️ |
|
||||
| `batch_delete([...])` | You have a list of IDs to purge | ✔️ | ✖️ |
|
||||
| `delete_all(...)` | You need to forget a user/agent/run | ✖️ | ✔️ |
|
||||
|
||||
## Put it into practice
|
||||
|
||||
- Review the <Link href="/api-reference/memory/delete-memory">Delete Memory API reference</Link>, plus <Link href="/api-reference/memory/batch-delete">Batch Delete</Link> and <Link href="/api-reference/memory/delete-memories">Filtered Delete</Link>.
|
||||
- Pair deletes with <Link href="/platform/features/expiration-date">Expiration Policies</Link> to automate retention.
|
||||
|
||||
## See it live
|
||||
|
||||
- <Link href="/examples/customer-support-agent">Customer Support Agent</Link> demonstrates compliance-driven deletes.
|
||||
- <Link href="/platform/features/direct-import">Data Management tooling</Link> shows how deletes fit into broader lifecycle flows.
|
||||
|
||||
{/* DEBUG: verify CTA targets */}
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card
|
||||
title="Review Add Concepts"
|
||||
description="Ensure the memories you keep are structured from the start."
|
||||
icon="circle-check"
|
||||
href="/core-concepts/memory-operations/add"
|
||||
/>
|
||||
<Card
|
||||
title="Enable Expiration Policies"
|
||||
description="Automate retention with the platform’s expiration feature."
|
||||
icon="clock"
|
||||
href="/platform/features/expiration-date"
|
||||
/>
|
||||
</CardGroup>
|
||||
|
||||
@@ -5,20 +5,23 @@ icon: "magnifying-glass"
|
||||
iconType: "solid"
|
||||
---
|
||||
|
||||
## Overview
|
||||
# How Mem0 Searches Memory
|
||||
|
||||
The `search` operation allows you to retrieve relevant memories based on a natural language query and optional filters like user ID, agent ID, categories, and more. This is the foundation of giving your agents memory-aware behavior.
|
||||
Mem0’s search operation lets agents ask natural-language questions and get back the memories that matter most. It’s the bridge between everything you’ve stored and the next response your agent writes.
|
||||
|
||||
Mem0 supports:
|
||||
- Semantic similarity search
|
||||
- Metadata filtering (with advanced logic)
|
||||
- Reranking and thresholds
|
||||
- Cross-agent, multi-session context resolution
|
||||
<Info>
|
||||
**Why it matters**
|
||||
- Retrieves the right facts without rebuilding prompts from scratch.
|
||||
- Supports both managed Platform and OSS so you can test locally and deploy at scale.
|
||||
- Keeps results relevant with filters, rerankers, and thresholds.
|
||||
</Info>
|
||||
|
||||
This applies to both:
|
||||
- **Mem0 Platform** (hosted API with full-scale features)
|
||||
- **Mem0 Open Source** (local-first with LLM inference and local vector DB)
|
||||
## Key terms
|
||||
|
||||
- **Query** – Natural-language question or statement you pass to `search`.
|
||||
- **Filters** – JSON logic (AND/OR, comparison operators) that narrows results by user, categories, dates, etc.
|
||||
- **top_k / threshold** – Controls how many memories return and the minimum similarity score.
|
||||
- **Rerank** – Optional second pass that boosts precision when a reranker is configured.
|
||||
|
||||
## Architecture
|
||||
|
||||
@@ -26,23 +29,26 @@ This applies to both:
|
||||
<img src="../../images/search_architecture.png" />
|
||||
</Frame>
|
||||
|
||||
When you call `search`, Mem0 performs the following steps:
|
||||
<Steps>
|
||||
<Step title="Query processing">
|
||||
Mem0 cleans and enriches your natural-language query so the downstream embedding search is accurate.
|
||||
</Step>
|
||||
<Step title="Vector search">
|
||||
Embeddings locate the closest memories using cosine similarity across your scoped dataset.
|
||||
</Step>
|
||||
<Step title="Filtering & reranking">
|
||||
Logical filters narrow candidates; rerankers or thresholds fine-tune ordering.
|
||||
</Step>
|
||||
<Step title="Results delivery">
|
||||
Formatted memories (with metadata and timestamps) return to your agent or calling service.
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
1. **Query Processing**
|
||||
An LLM refines and optimizes your natural language query.
|
||||
|
||||
2. **Vector Search**
|
||||
Semantic embeddings are used to find the most relevant memories using cosine similarity.
|
||||
|
||||
3. **Filtering & Ranking**
|
||||
Logical and comparison-based filters are applied. Memories are scored, filtered, and optionally reranked.
|
||||
|
||||
4. **Results Delivery**
|
||||
Relevant memories are returned with associated metadata and timestamps.
|
||||
This pipeline runs the same way for the hosted Platform API and the OSS SDK.
|
||||
|
||||
---
|
||||
|
||||
## Example: Mem0 Platform
|
||||
## Search with Mem0 Platform
|
||||
|
||||
<CodeGroup>
|
||||
```python Python
|
||||
@@ -81,7 +87,7 @@ const results = await client.search(query, {
|
||||
|
||||
---
|
||||
|
||||
## Example: Mem0 Open Source
|
||||
## Search with Mem0 Open Source
|
||||
|
||||
<CodeGroup>
|
||||
```python Python
|
||||
@@ -118,7 +124,11 @@ const memories = memory.search("food preferences", {
|
||||
|
||||
---
|
||||
|
||||
## Using Filters
|
||||
<Info icon="check">
|
||||
Expect an array of memory documents. Platform responses include vectors, metadata, and timestamps; OSS returns your stored schema.
|
||||
</Info>
|
||||
|
||||
## Filter patterns
|
||||
|
||||
Filters help narrow down search results. Common use cases:
|
||||
|
||||
@@ -152,7 +162,7 @@ client.search("preferences", filters={
|
||||
|
||||
---
|
||||
|
||||
## Tips for Better Search
|
||||
## Tips for better search
|
||||
|
||||
- **Use natural language**: Mem0 understands intent, so describe what you're looking for naturally
|
||||
- **Scope with session IDs**: Always provide at least `user_id` to scope search to relevant memories
|
||||
@@ -167,7 +177,38 @@ client.search("preferences", filters={
|
||||
For the full list of filter logic, comparison operators, and optional search parameters, see the
|
||||
[Search Memory API Reference](/api-reference/memory/search-memories).
|
||||
|
||||
## Need help?
|
||||
If you have any questions, please feel free to reach out to us using one of the following methods:
|
||||
## Managed vs OSS differences
|
||||
|
||||
<Snippet file="get-help.mdx"/>
|
||||
| Capability | Mem0 Platform | Mem0 OSS |
|
||||
| --- | --- | --- |
|
||||
| Filters | Logical operators (`AND`, `OR`, comparisons) with field-level access | Basic field filters, extend via Python hooks |
|
||||
| Reranking | Toggle `rerank=True` with managed reranker catalog | Requires configuring local or third-party rerankers |
|
||||
| Thresholds | Request-level configuration (`threshold`, `top_k`) | Controlled via SDK parameters |
|
||||
| Response metadata | Includes confidence scores, timestamps, dashboard visibility | Determined by your storage backend |
|
||||
|
||||
## Put it into practice
|
||||
|
||||
- Revisit the <Link href="/core-concepts/memory-operations/add">Add Memory</Link> guide to ensure you capture the context you expect to retrieve.
|
||||
- Configure rerankers and filters in <Link href="/platform/features/advanced-retrieval">Advanced Retrieval</Link> for higher precision.
|
||||
|
||||
## See it live
|
||||
|
||||
- <Link href="/examples/customer-support-agent">Customer Support Agent</Link> demonstrates scoped search with rerankers.
|
||||
- <Link href="/examples/personalized-search-tavily-mem0">Personalized Search with Tavily</Link> shows hybrid search in action.
|
||||
|
||||
{/* DEBUG: verify CTA targets */}
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card
|
||||
title="Tune Update Concepts"
|
||||
description="Learn how to adjust memories after search results come back."
|
||||
icon="pencil"
|
||||
href="/core-concepts/memory-operations/update"
|
||||
/>
|
||||
<Card
|
||||
title="Build Hybrid Search"
|
||||
description="Follow the cookbook to combine Mem0 with external search."
|
||||
icon="rocket"
|
||||
href="/examples/personalized-search-tavily-mem0"
|
||||
/>
|
||||
</CardGroup>
|
||||
|
||||
@@ -5,29 +5,40 @@ icon: "pen-to-square"
|
||||
iconType: "solid"
|
||||
---
|
||||
|
||||
## Overview
|
||||
# Keep Memories Accurate with Update
|
||||
|
||||
User preferences, interests, and behaviors often evolve over time. The `update` operation lets you revise a stored memory, whether it's updating facts, rephrasing a message, or enriching metadata.
|
||||
Mem0’s update operation lets you fix or enrich an existing memory without deleting it. When a user changes their preference or clarifies a fact, use update to keep the knowledge base fresh.
|
||||
|
||||
Mem0 supports both:
|
||||
- **Single Memory Update** for one specific memory using its ID
|
||||
- **Batch Update** for updating many memories at once (up to 1000)
|
||||
<Info>
|
||||
**Why it matters**
|
||||
- Corrects outdated or incorrect memories immediately.
|
||||
- Adds new metadata so filters and rerankers stay sharp.
|
||||
- Works for both one-off edits and large batches (up to 1000 memories).
|
||||
</Info>
|
||||
|
||||
This guide includes usage for both single update and batch update of memories through **Mem0 Platform**.
|
||||
## Key terms
|
||||
|
||||
- **memory_id** – Unique identifier returned by `add` or `search` results.
|
||||
- **text** / **data** – New content that replaces the stored memory value.
|
||||
- **metadata** – Optional key-value pairs you update alongside the text.
|
||||
- **batch_update** – Platform API that edits multiple memories in a single request.
|
||||
- **immutable** – Flagged memories that must be deleted and re-added instead of updated.
|
||||
|
||||
## Use Cases
|
||||
## How the update flow works
|
||||
|
||||
- Refine a vague or incorrect memory after a correction
|
||||
- Add or edit memory with new metadata (e.g., categories, tags)
|
||||
- Evolve factual knowledge as the user's profile changes
|
||||
- Handle profile evolution: "I love spicy food" → later says "Actually, I can't handle spicy food"
|
||||
<Steps>
|
||||
<Step title="Locate the memory">
|
||||
Use `search` or dashboard inspection to capture the `memory_id` you want to change.
|
||||
</Step>
|
||||
<Step title="Submit the update">
|
||||
Call `update` (or `batch_update`) with new text and optional metadata. Mem0 overwrites the stored value and adjusts indexes.
|
||||
</Step>
|
||||
<Step title="Verify">
|
||||
Check the response or re-run `search` to ensure the revised memory appears with the new content.
|
||||
</Step>
|
||||
</Steps>
|
||||
|
||||
Updating memory ensures your agents remain accurate, adaptive, and personalized.
|
||||
|
||||
---
|
||||
|
||||
## Update Memory
|
||||
## Single memory update (Platform)
|
||||
|
||||
<CodeGroup>
|
||||
```python Python
|
||||
@@ -49,18 +60,18 @@ import MemoryClient from 'mem0ai';
|
||||
const client = new MemoryClient({ apiKey: "your-api-key" });
|
||||
const memory_id = "your_memory_id";
|
||||
|
||||
client.update(memory_id, {
|
||||
await client.update(memory_id, {
|
||||
text: "Updated memory content about the user",
|
||||
metadata: { category: "profile-update" }
|
||||
})
|
||||
.then(result => console.log(result))
|
||||
.catch(error => console.error(error));
|
||||
});
|
||||
```
|
||||
</CodeGroup>
|
||||
|
||||
---
|
||||
<Info icon="check">
|
||||
Expect a confirmation message and the updated memory to appear in the dashboard almost instantly.
|
||||
</Info>
|
||||
|
||||
## Batch Update
|
||||
## Batch update (Platform)
|
||||
|
||||
Update up to 1000 memories in one call.
|
||||
|
||||
@@ -95,21 +106,66 @@ client.batchUpdate(updateMemories)
|
||||
```
|
||||
</CodeGroup>
|
||||
|
||||
---
|
||||
## Update with Mem0 OSS
|
||||
|
||||
<CodeGroup>
|
||||
```python Python
|
||||
from mem0 import Memory
|
||||
|
||||
memory = Memory()
|
||||
|
||||
memory.update(
|
||||
memory_id="mem_123",
|
||||
data="Alex now prefers decaf coffee",
|
||||
)
|
||||
```
|
||||
```
|
||||
```
|
||||
</CodeGroup>
|
||||
|
||||
<Note>
|
||||
OSS JavaScript SDK does not expose `update` yet—use the REST API or Python SDK when self-hosting.
|
||||
</Note>
|
||||
|
||||
## Tips
|
||||
|
||||
- You can update both `text` and `metadata` in the same call
|
||||
- Use `batchUpdate` when you're applying similar corrections at scale
|
||||
- If memory is marked `immutable`, it must first be deleted and re-added
|
||||
- Combine this with feedback mechanisms (e.g., user thumbs-up/down) to self-improve memory
|
||||
- Update both `text` **and** `metadata` together to keep filters accurate.
|
||||
- Batch updates are ideal after large imports or when syncing CRM corrections.
|
||||
- Immutable memories must be deleted and re-added instead of updated.
|
||||
- Pair updates with feedback signals (thumbs up/down) to self-heal memories automatically.
|
||||
|
||||
## Managed vs OSS differences
|
||||
|
||||
### More Details
|
||||
| Capability | Mem0 Platform | Mem0 OSS |
|
||||
| --- | --- | --- |
|
||||
| Update call | `client.update(memory_id, {...})` | `memory.update(memory_id, data=...)` |
|
||||
| Batch updates | `client.batch_update` (up to 1000 memories) | Script your own loop or bulk job |
|
||||
| Dashboard visibility | Inspect updates in the UI | Inspect via logs or custom tooling |
|
||||
| Immutable handling | Returns descriptive error | Raises exception—delete and re-add |
|
||||
|
||||
Refer to the full [Update Memory API Reference](/api-reference/memory/update-memory) and [Batch Update Reference](/api-reference/memory/batch-update) for schema and advanced fields.
|
||||
## Put it into practice
|
||||
|
||||
## Need help?
|
||||
If you have any questions, please feel free to reach out to us using one of the following methods:
|
||||
- Review the <Link href="/api-reference/memory/update-memory">Update Memory API reference</Link> for request/response details.
|
||||
- Combine updates with <Link href="/platform/features/feedback-mechanism">Feedback Mechanism</Link> to automate corrections.
|
||||
|
||||
<Snippet file="get-help.mdx"/>
|
||||
## See it live
|
||||
|
||||
- <Link href="/examples/customer-support-agent">Customer Support Agent</Link> uses updates to refine customer profiles.
|
||||
- <Link href="/examples/personal-ai-tutor">Personal AI Tutor</Link> demonstrates user preference corrections mid-course.
|
||||
|
||||
{/* DEBUG: verify CTA targets */}
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card
|
||||
title="Learn Delete Concepts"
|
||||
description="Understand when to remove memories instead of editing them."
|
||||
icon="trash"
|
||||
href="/core-concepts/memory-operations/delete"
|
||||
/>
|
||||
<Card
|
||||
title="Automate Corrections"
|
||||
description="See how feedback loops trigger updates in production."
|
||||
icon="rocket"
|
||||
href="/platform/features/feedback-mechanism"
|
||||
/>
|
||||
</CardGroup>
|
||||
|
||||
@@ -1,50 +1,129 @@
|
||||
---
|
||||
title: Memory Types
|
||||
description: Understanding different types of memory in AI Applications
|
||||
icon: "memory"
|
||||
description: "See how Mem0 layers conversation, session, and user memories to keep agents contextual."
|
||||
icon: "tag"
|
||||
iconType: "solid"
|
||||
---
|
||||
|
||||
To build useful AI applications, we need to understand how different memory systems work together. This guide explores the fundamental types of memory in AI systems and shows how Mem0 implements these concepts.
|
||||
# How Mem0 Organizes Memory
|
||||
|
||||
## Why Memory Matters
|
||||
Mem0 separates memory into layers so agents remember the right detail at the right time. Think of it like a notebook: a sticky note for the current task, a daily journal for the session, and an archive for everything a user has shared.
|
||||
|
||||
AI systems need memory for three key purposes:
|
||||
1. Maintaining context during conversations
|
||||
2. Learning from past interactions
|
||||
3. Building personalized experiences over time
|
||||
<Info>
|
||||
**Why it matters**
|
||||
- Keeps conversations coherent without repeating instructions.
|
||||
- Lets agents personalize responses based on long-term preferences.
|
||||
- Avoids over-fetching data by scoping memory to the correct layer.
|
||||
</Info>
|
||||
|
||||
Without proper memory systems, AI applications would treat each interaction as completely new, losing valuable context and personalization opportunities.
|
||||
## Key terms
|
||||
|
||||
## Short-Term Memory
|
||||
- **Conversation memory** – In-flight messages inside a single turn (what was just said).
|
||||
- **Session memory** – Short-lived facts that apply for the current task or channel.
|
||||
- **User memory** – Long-lived knowledge tied to a person, account, or workspace.
|
||||
- **Organizational memory** – Shared context available to multiple agents or teams.
|
||||
|
||||
The most basic form of memory in AI systems holds immediate context - like a person remembering what was just said in a conversation. This includes:
|
||||
```mermaid
|
||||
graph LR
|
||||
A[Conversation turn] --> B[Session memory]
|
||||
B --> C[User memory]
|
||||
C --> D[Org memory]
|
||||
C --> E[Mem0 retrieval layer]
|
||||
```
|
||||
|
||||
- **Conversation History**: Recent messages and their order
|
||||
- **Working Memory**: Temporary variables and state
|
||||
- **Attention Context**: Current focus of the conversation
|
||||
## Short-term vs long-term memory
|
||||
|
||||
## Long-Term Memory
|
||||
Short-term memory keeps the current conversation coherent. It includes:
|
||||
|
||||
More sophisticated AI applications implement long-term memory to retain information across conversations. This includes:
|
||||
- **Conversation history** – recent turns in order so the agent remembers what was just said.
|
||||
- **Working memory** – temporary state such as tool outputs or intermediate calculations.
|
||||
- **Attention context** – the immediate focus of the assistant, similar to what a person holds in mind mid-sentence.
|
||||
|
||||
- **Factual Memory**: Stored knowledge about users, preferences, and domain-specific information
|
||||
- **Episodic Memory**: Past interactions and experiences
|
||||
- **Semantic Memory**: Understanding of concepts and their relationships
|
||||
Long-term memory preserves knowledge across sessions. It captures:
|
||||
|
||||
## Memory Characteristics
|
||||
- **Factual memory** – user preferences, account details, and domain facts.
|
||||
- **Episodic memory** – summaries of past interactions or completed tasks.
|
||||
- **Semantic memory** – relationships between concepts so agents can reason about them later.
|
||||
|
||||
Each memory type has distinct characteristics:
|
||||
Mem0 maps these classic categories onto its layered storage so you can decide what should fade quickly versus what should last for months.
|
||||
|
||||
| Type | Persistence | Access Speed | Use Case |
|
||||
|------|-------------|--------------|-----------|
|
||||
| Short-Term | Temporary | Instant | Active conversations |
|
||||
| Long-Term | Persistent | Fast | User preferences and history |
|
||||
## How does it work?
|
||||
|
||||
## How Mem0 Implements Long-Term Memory
|
||||
Mem0 stores each layer separately and merges them when you query:
|
||||
|
||||
Mem0's long-term memory system builds on these foundations by:
|
||||
1. **Capture** – Messages enter the conversation layer while the turn is active.
|
||||
2. **Promote** – Relevant details persist to session or user memory based on your `user_id`, `session_id`, and metadata.
|
||||
3. **Retrieve** – The search pipeline pulls from all layers, ranking user memories first, then session notes, then raw history.
|
||||
|
||||
1. Using vector embeddings to store and retrieve semantic information
|
||||
2. Maintaining user-specific context across sessions
|
||||
3. Implementing efficient retrieval mechanisms for relevant past interactions
|
||||
```python
|
||||
import os
|
||||
|
||||
from mem0 import Memory
|
||||
|
||||
memory = Memory(api_key=os.environ["MEM0_API_KEY"])
|
||||
|
||||
# Sticky note: conversation memory
|
||||
memory.add(
|
||||
["I'm Alex and I prefer boutique hotels."],
|
||||
user_id="alex",
|
||||
session_id="trip-planning-2025",
|
||||
)
|
||||
|
||||
# Later in the session, pull long-term + session context
|
||||
results = memory.search(
|
||||
"Any hotel preferences?",
|
||||
user_id="alex",
|
||||
session_id="trip-planning-2025",
|
||||
)
|
||||
```
|
||||
|
||||
<Tip>
|
||||
Use `session_id` when you want short-term context to expire automatically; rely on `user_id` for lasting personalization.
|
||||
</Tip>
|
||||
|
||||
## When should you use each layer?
|
||||
|
||||
- **Conversation memory** – Tool calls or chain-of-thought that only matter within the current turn.
|
||||
- **Session memory** – Multi-step tasks (onboarding flows, debugging sessions) that should reset once complete.
|
||||
- **User memory** – Personal preferences, account state, or compliance details that must persist across interactions.
|
||||
- **Organizational memory** – Shared FAQs, product catalogs, or policies that every agent should recall.
|
||||
|
||||
## How it compares
|
||||
|
||||
| Layer | Lifetime | Short or long term | Best for | Trade-offs |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| Conversation | Single response | Short-term | Tool execution detail | Lost after the turn finishes |
|
||||
| Session | Minutes to hours | Short-term | Multi-step flows | Clear it manually when done |
|
||||
| User | Weeks to forever | Long-term | Personalization | Requires consent/governance |
|
||||
| Org | Configured globally | Long-term | Shared knowledge | Needs owner to keep current |
|
||||
|
||||
<Warning>
|
||||
Avoid storing secrets or unredacted PII in user or org memories—Mem0 is retrievable by design. Encrypt or hash sensitive values first.
|
||||
</Warning>
|
||||
|
||||
## Put it into practice
|
||||
|
||||
- Use the <Link href="/core-concepts/memory-operations/add">Add Memory</Link> guide to persist user preferences.
|
||||
- Follow <Link href="/platform/advanced-memory-operations">Advanced Memory Operations</Link> to tune metadata and graph writes.
|
||||
|
||||
## See it live
|
||||
|
||||
- <Link href="/examples/personal-ai-tutor">Personal AI Tutor</Link> shows session vs user memories in action.
|
||||
- <Link href="/examples/customer-support-agent">Customer Support Agent</Link> demonstrates shared org memory.
|
||||
|
||||
{/* DEBUG: verify CTA targets */}
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card
|
||||
title="Explore Memory Operations"
|
||||
description="Dive into the add/search/update/delete concepts next."
|
||||
icon="circle-check"
|
||||
href="/core-concepts/memory-operations/add"
|
||||
/>
|
||||
<Card
|
||||
title="See a Cookbook"
|
||||
description="Apply layered memories inside a customer support agent."
|
||||
icon="rocket"
|
||||
href="/examples/customer-support-agent"
|
||||
/>
|
||||
</CardGroup>
|
||||
|
||||
Reference in New Issue
Block a user