[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>
|
||||
|
||||
Reference in New Issue
Block a user