docs: remove memory types page and preserve redirects (#7437)
This commit is contained in:
Kartik
@@ -89,8 +89,8 @@ On Mem0 Platform, these stores are managed for you. In OSS, you choose and opera
|
||||
## Next steps
|
||||
|
||||
<CardGroup cols={3}>
|
||||
<Card title="Memory types" icon="brain" href="/core-concepts/memory-types">
|
||||
Choose the right scope for user, agent, run, and session memory.
|
||||
<Card title="Entity scoping" icon="brain" href="/platform/features/entity-scoped-memory">
|
||||
Organize Platform memories by user, agent, app, and run.
|
||||
</Card>
|
||||
<Card title="Memory operations" icon="database" href="/core-concepts/memory-operations/add">
|
||||
Add, search, update, and delete memories from your app.
|
||||
|
||||
@@ -1,118 +0,0 @@
|
||||
---
|
||||
title: Memory Types
|
||||
description: "What memory_type actually does in Mem0: procedural memory is implemented, semantic and episodic are not."
|
||||
icon: "tag"
|
||||
iconType: "solid"
|
||||
---
|
||||
|
||||
# Memory Types
|
||||
|
||||
Mem0's Python SDK exposes a `memory_type` parameter on `add()`. The underlying `MemoryType` enum defines three values, but only one of them is wired up. This page states plainly which is which so you don't build against a type that doesn't exist yet.
|
||||
|
||||
## Status
|
||||
|
||||
| Type | Enum value | Status | Notes |
|
||||
| --- | --- | --- | --- |
|
||||
| Procedural memory | `procedural_memory` | **Implemented** | Python OSS only (`Memory`/`AsyncMemory`). Pass `memory_type="procedural_memory"` and `agent_id` to `add()`. Not available on the Platform `MemoryClient`, and not available in the TypeScript SDK (OSS or Platform). |
|
||||
| Semantic memory | `semantic_memory` | **Not implemented** | Defined in the `MemoryType` enum but never read anywhere else in the codebase. Passing it to `add()` raises a validation error. There is no evidence in this repo of a roadmap date for this. |
|
||||
| Episodic memory | `episodic_memory` | **Not implemented** | Same as above: defined, never wired into the extraction pipeline, rejected by validation, no documented roadmap. |
|
||||
|
||||
<Warning>
|
||||
Only `procedural_memory` is a real, working value. Calling `memory.add(messages, memory_type="semantic_memory")` (or `episodic_memory`) is rejected and tells you to pass `procedural_memory` instead. Sync `Memory.add()` raises `Mem0ValidationError`; `AsyncMemory.add()` raises a plain `ValueError`.
|
||||
</Warning>
|
||||
|
||||
## Procedural memory
|
||||
|
||||
Procedural memory stores step-by-step task knowledge (how an agent performs a workflow) rather than facts about a user. It requires `agent_id`:
|
||||
|
||||
```python
|
||||
from mem0 import Memory
|
||||
|
||||
memory = Memory()
|
||||
|
||||
memory.add(
|
||||
[
|
||||
{"role": "user", "content": "Book a flight from SFO to NYC"},
|
||||
{"role": "assistant", "content": "1. Search flights. 2. Filter by price. 3. Confirm booking."},
|
||||
],
|
||||
agent_id="travel-agent",
|
||||
memory_type="procedural_memory",
|
||||
)
|
||||
```
|
||||
|
||||
Omit `memory_type` entirely and Mem0 stores the messages as an ordinary memory: there is no semantic/episodic pathway for it to fall into. Any other explicit value is rejected by validation rather than quietly falling back to an ordinary memory.
|
||||
|
||||
## How every other memory is scoped
|
||||
|
||||
Outside of the `procedural_memory` special case, Mem0 does not sort memories into named types. Every memory is scoped by the identifiers you pass in, and the same identifiers are used to retrieve it later:
|
||||
|
||||
- **`user_id`**: ties a memory to a specific person or account.
|
||||
- **`agent_id`**: ties a memory to a specific agent or assistant persona.
|
||||
- **`run_id`**: ties a memory to a specific session, task, or conversation thread.
|
||||
- **`app_id`** (Platform only): ties a memory to a specific application or tenant, in addition to the three above. See <Link href="/platform/features/entity-scoped-memory">Entity-Scoped Memory</Link>.
|
||||
|
||||
At least one identifier is required on `add()`. Passing more than one narrows the scope further (for example, `user_id` + `run_id` together).
|
||||
|
||||
```python
|
||||
from mem0 import Memory
|
||||
|
||||
memory = Memory()
|
||||
|
||||
memory.add(
|
||||
"I'm Alex and I prefer boutique hotels.",
|
||||
user_id="alex",
|
||||
run_id="trip-planning-2025",
|
||||
)
|
||||
|
||||
results = memory.search(
|
||||
"Any hotel preferences?",
|
||||
filters={"user_id": "alex", "run_id": "trip-planning-2025"},
|
||||
)
|
||||
```
|
||||
|
||||
<Tip>
|
||||
Use `run_id` when you want a set of memories to stay tied to one session or task; use `user_id` alone for anything that should persist across every session for that person.
|
||||
</Tip>
|
||||
|
||||
## How memories are extracted and updated
|
||||
|
||||
When `infer=True` (the default) on `add()`, Mem0 runs a single pipeline rather than routing through separate type-specific paths:
|
||||
|
||||
1. **Context gathering**: pulls the most recent messages already stored for the same `user_id`/`agent_id`/`run_id` scope.
|
||||
2. **Existing memory retrieval**: embeds the new messages and runs a vector search against memories already in that same scope, to find candidates that might need to change.
|
||||
3. **Extraction**: a single LLM call compares the new messages against the retrieved candidates and decides, per fact, whether to `ADD`, `UPDATE`, `DELETE`, or leave a memory alone.
|
||||
|
||||
Alongside this, both OSS and Platform extract named entities (people, places, organizations) from memory text and use shared entities between memories to boost related results at search time. On Platform, that entity graph is also queryable directly; see <Link href="/platform/features/graph-memory">Graph Memory</Link>. In OSS, entities only affect ranking, there is no separate graph to query.
|
||||
|
||||
<Warning>
|
||||
Avoid storing secrets or unredacted PII in memories: they are retrievable by design. Encrypt or hash sensitive values before calling `add()`.
|
||||
</Warning>
|
||||
|
||||
## Put it into practice
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card
|
||||
title="Explore Memory Operations"
|
||||
description="Dive into the add/search/update/delete operations next."
|
||||
icon="circle-check"
|
||||
href="/core-concepts/memory-operations/add"
|
||||
/>
|
||||
<Card
|
||||
title="Advanced Memory Operations"
|
||||
description="Tune metadata, filters, and retrieval on Platform."
|
||||
icon="sliders"
|
||||
href="/platform/advanced-memory-operations"
|
||||
/>
|
||||
<Card
|
||||
title="AI Tutor Cookbook"
|
||||
description="See user_id-scoped memory used in a real tutoring agent."
|
||||
icon="rocket"
|
||||
href="/cookbooks/companions/ai-tutor"
|
||||
/>
|
||||
<Card
|
||||
title="Support Inbox Cookbook"
|
||||
description="See user_id-scoped memory used in a support workflow."
|
||||
icon="inbox"
|
||||
href="/cookbooks/operations/support-inbox"
|
||||
/>
|
||||
</CardGroup>
|
||||
+5
-2
@@ -54,7 +54,6 @@
|
||||
"icon": "brain",
|
||||
"pages": [
|
||||
"core-concepts/how-it-works",
|
||||
"core-concepts/memory-types",
|
||||
"core-concepts/memory-operations/add",
|
||||
"core-concepts/memory-operations/search",
|
||||
"core-concepts/memory-operations/update",
|
||||
@@ -1033,7 +1032,11 @@
|
||||
},
|
||||
{
|
||||
"source": "/concepts/memory-scoring",
|
||||
"destination": "/core-concepts/memory-types"
|
||||
"destination": "/core-concepts/how-it-works"
|
||||
},
|
||||
{
|
||||
"source": "/core-concepts/memory-types",
|
||||
"destination": "/core-concepts/how-it-works"
|
||||
},
|
||||
{
|
||||
"source": "/cookbooks/research-copilot",
|
||||
|
||||
@@ -130,10 +130,10 @@ print(response.msgs[0].content)
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card
|
||||
title="Memory types in Mem0"
|
||||
description="Choose between chat history and semantic search for your Camel agents."
|
||||
title="How Mem0 works"
|
||||
description="Understand how Mem0 extracts, stores, and retrieves memories for your Camel agents."
|
||||
icon="sparkles"
|
||||
href="/core-concepts/memory-types"
|
||||
href="/core-concepts/how-it-works"
|
||||
/>
|
||||
<Card
|
||||
title="Try LangChain next"
|
||||
|
||||
@@ -186,7 +186,6 @@ If the user is on a pre-current major (Python < 2, TS < 3, or a Platform call st
|
||||
## Core Concepts
|
||||
|
||||
- [How Mem0 Works](https://docs.mem0.ai/core-concepts/how-it-works) [Both]: Use when explaining the end-to-end pipeline: extraction (ADD-only distillation), storage across vector/entity/history stores, and multi-signal retrieval.
|
||||
- [Memory Types](https://docs.mem0.ai/core-concepts/memory-types) [Both]: Use when checking which `memory_type` values actually work: `procedural_memory` is implemented, `semantic_memory` and `episodic_memory` are defined in the enum but rejected by validation.
|
||||
- [Memory Operations - Add](https://docs.mem0.ai/core-concepts/memory-operations/add) [Both]: Use when explaining how `add()` extracts facts, resolves conflicts, and writes to both stores.
|
||||
- [Memory Operations - Search](https://docs.mem0.ai/core-concepts/memory-operations/search) [Both]: Use when explaining how queries are processed and ranked.
|
||||
- [Memory Operations - Update](https://docs.mem0.ai/core-concepts/memory-operations/update) [Both]: Use when memories need to be edited in place or reconciled against new info.
|
||||
|
||||
@@ -50,8 +50,8 @@ For the full pipeline, see [How Mem0 works](/core-concepts/how-it-works).
|
||||
<Card title="Run the quickstart" icon="rocket" href="/platform/quickstart">
|
||||
Get an API key and save your first memory.
|
||||
</Card>
|
||||
<Card title="Understand memory types" icon="brain" href="/core-concepts/memory-types">
|
||||
How user, agent, app, and run memory differ.
|
||||
<Card title="Scope your memories" icon="brain" href="/platform/features/entity-scoped-memory">
|
||||
Organize memories by user, agent, app, and run.
|
||||
</Card>
|
||||
<Card title="Add, search, and update" icon="layer-group" href="/core-concepts/memory-operations/add">
|
||||
The core memory operations, end to end.
|
||||
|
||||
@@ -39,7 +39,7 @@ The core memory loop is identical on both: `add`, `search`, `get`, `get_all`, `u
|
||||
- **Entity scoping** by `user_id`, `agent_id`, and `run_id`
|
||||
- **Filter grouping**: both accept `AND`/`OR`/`NOT` wrappers, both implicitly AND a flat multi-key filter like `{"user_id": "alice", "agent_id": "a1"}`, and both accept `*` as a wildcard value. Which fields you may filter on, and which operators each field accepts, differ (see below)
|
||||
- **Entity-aware ranking**: both extract entities from memory text and use shared entities to boost related results at search time
|
||||
- **Multimodal input**, **memory expiration** (`expiration_date`), **reranking**, **procedural memory** (Python), and **custom extraction instructions** (`custom_instructions`)
|
||||
- **Multimodal input**, **memory expiration** (`expiration_date`), **reranking**, and **custom extraction instructions** (`custom_instructions`)
|
||||
- Python and JavaScript SDKs, plus a REST API (self-hosted via `server/`, or hosted)
|
||||
|
||||
## What's actually different
|
||||
|
||||
+1
-1
@@ -124,7 +124,7 @@ Walk through a real request/response. Include sample payloads and highlight nota
|
||||
{/* DEBUG: verify CTA targets */}
|
||||
|
||||
<CardGroup cols={2}>
|
||||
<Card title="Dive Into Memory Scoring" icon="scale-balanced" href="/core-concepts/memory-types">
|
||||
<Card title="Dive Into Memory Scoring" icon="scale-balanced" href="/core-concepts/how-it-works">
|
||||
Understand how Mem0 ranks memories under the hood.
|
||||
</Card>
|
||||
<Card title="Build a Research Copilot" icon="book-open" href="/cookbooks/operations/deep-research">
|
||||
|
||||
+2
-4
@@ -38,7 +38,6 @@ client.memories.add(
|
||||
user_id: str,
|
||||
memory: str,
|
||||
metadata: Optional[dict] = None,
|
||||
memory_type: Literal["session", "long_term"] = "session",
|
||||
)
|
||||
```
|
||||
|
||||
@@ -47,13 +46,13 @@ await mem0.memories.add({
|
||||
userId: string;
|
||||
memory: string;
|
||||
metadata?: Record<string, string>;
|
||||
memoryType?: "session" | "long_term";
|
||||
});
|
||||
```
|
||||
</CodeGroup>
|
||||
|
||||
<Info>
|
||||
Defaults to session memories. Override `memory_type` for long-term storage.
|
||||
[Describe defaults supported by this operation and SDK. Do not infer a
|
||||
memory type or retention policy from a scoping identifier.]
|
||||
</Info>
|
||||
|
||||
<Warning>
|
||||
@@ -67,7 +66,6 @@ await mem0.memories.add({
|
||||
| `user_id` | string | Yes | Unique identifier for the end user. | Must match follow-up operations. |
|
||||
| `memory` | string | Yes | Content to persist. | Managed & OSS. Markdown allowed. |
|
||||
| `metadata` | object | No | Key-value pairs for filters. | OSS stores as JSONB; limit to 2KB. |
|
||||
| `memory_type` | string | No | Retention bucket | Platform supports `shared`. |
|
||||
|
||||
<Tip>
|
||||
Set `ttl_seconds` when you need memories to expire automatically (OSS only).
|
||||
|
||||
+2
-2
@@ -96,8 +96,8 @@ time. Storage: vector embeddings.
|
||||
**Architecture Overview:**
|
||||
- Memory is scoped by user_id, agent_id, or run_id
|
||||
- Core operations: add, search, update, delete
|
||||
- Memory types: factual (preferences, facts), episodic (past interactions),
|
||||
semantic (concept relationships), working (session state)
|
||||
- Store preferences, facts, and past interactions; use run_id to scope a
|
||||
session. Platform does not expose a memory_type selector.
|
||||
- Integration pattern: retrieve relevant memories → generate response → store
|
||||
new memories
|
||||
|
||||
|
||||
@@ -125,6 +125,8 @@ export interface Memory {
|
||||
categories?: Array<string>;
|
||||
createdAt?: Date;
|
||||
updatedAt?: Date;
|
||||
// TODO: Review this response field for removal in a future breaking release.
|
||||
// It is not a selectable memory type; TypeScript has no procedural-memory path.
|
||||
memoryType?: string;
|
||||
score?: number;
|
||||
metadata?: any | null;
|
||||
|
||||
@@ -850,6 +850,8 @@ class Memory(MemoryBase):
|
||||
suggestion="Convert your input to a string, dictionary, or list of dictionaries."
|
||||
)
|
||||
|
||||
# TODO: Remove procedural-memory support in a future breaking release.
|
||||
# Remove memory_type and its helpers from Memory and AsyncMemory together.
|
||||
if agent_id is not None and memory_type == MemoryType.PROCEDURAL.value:
|
||||
results = self._create_procedural_memory(messages, metadata=processed_metadata, prompt=prompt)
|
||||
scale_threshold_notice = detect_scale_threshold_from_add_result(self, results)
|
||||
@@ -2502,6 +2504,8 @@ class AsyncMemory(MemoryBase):
|
||||
suggestion="Convert your input to a string, dictionary, or list of dictionaries."
|
||||
)
|
||||
|
||||
# TODO: Remove procedural-memory support in a future breaking release.
|
||||
# Remove memory_type and its helpers from Memory and AsyncMemory together.
|
||||
if agent_id is not None and memory_type == MemoryType.PROCEDURAL.value:
|
||||
results = await self._create_procedural_memory(
|
||||
messages, metadata=processed_metadata, prompt=prompt, llm=llm
|
||||
|
||||
Reference in New Issue
Block a user