diff --git a/docs/core-concepts/how-it-works.mdx b/docs/core-concepts/how-it-works.mdx index d650238a7..ac142cb10 100644 --- a/docs/core-concepts/how-it-works.mdx +++ b/docs/core-concepts/how-it-works.mdx @@ -89,8 +89,8 @@ On Mem0 Platform, these stores are managed for you. In OSS, you choose and opera ## Next steps - - Choose the right scope for user, agent, run, and session memory. + + Organize Platform memories by user, agent, app, and run. Add, search, update, and delete memories from your app. diff --git a/docs/core-concepts/memory-types.mdx b/docs/core-concepts/memory-types.mdx deleted file mode 100644 index a2a18e077..000000000 --- a/docs/core-concepts/memory-types.mdx +++ /dev/null @@ -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. | - - - 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`. - - -## 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 Entity-Scoped Memory. - -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"}, -) -``` - - - 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. - - -## 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 Graph Memory. In OSS, entities only affect ranking, there is no separate graph to query. - - - Avoid storing secrets or unredacted PII in memories: they are retrievable by design. Encrypt or hash sensitive values before calling `add()`. - - -## Put it into practice - - - - - - - diff --git a/docs/docs.json b/docs/docs.json index 969ebad35..4371c1ffe 100644 --- a/docs/docs.json +++ b/docs/docs.json @@ -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", diff --git a/docs/integrations/camel-ai.mdx b/docs/integrations/camel-ai.mdx index ced3ce266..8205e76f1 100644 --- a/docs/integrations/camel-ai.mdx +++ b/docs/integrations/camel-ai.mdx @@ -130,10 +130,10 @@ print(response.msgs[0].content) Get an API key and save your first memory. - - How user, agent, app, and run memory differ. + + Organize memories by user, agent, app, and run. The core memory operations, end to end. diff --git a/docs/platform/platform-vs-oss.mdx b/docs/platform/platform-vs-oss.mdx index 995b073bb..e4374ab1c 100644 --- a/docs/platform/platform-vs-oss.mdx +++ b/docs/platform/platform-vs-oss.mdx @@ -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 diff --git a/docs/templates/feature_guide_template.mdx b/docs/templates/feature_guide_template.mdx index fc502f88b..7582f3a47 100644 --- a/docs/templates/feature_guide_template.mdx +++ b/docs/templates/feature_guide_template.mdx @@ -124,7 +124,7 @@ Walk through a real request/response. Include sample payloads and highlight nota {/* DEBUG: verify CTA targets */} - + Understand how Mem0 ranks memories under the hood. diff --git a/docs/templates/parameters_reference_template.mdx b/docs/templates/parameters_reference_template.mdx index f86cb7745..b31d1b442 100644 --- a/docs/templates/parameters_reference_template.mdx +++ b/docs/templates/parameters_reference_template.mdx @@ -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; - memoryType?: "session" | "long_term"; }); ``` - 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.] @@ -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`. | Set `ttl_seconds` when you need memories to expire automatically (OSS only). diff --git a/docs/vibecoding.mdx b/docs/vibecoding.mdx index 0223bbc15..fef5f9e85 100644 --- a/docs/vibecoding.mdx +++ b/docs/vibecoding.mdx @@ -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 diff --git a/mem0-ts/src/client/mem0.types.ts b/mem0-ts/src/client/mem0.types.ts index 606cf0daf..a178f4529 100644 --- a/mem0-ts/src/client/mem0.types.ts +++ b/mem0-ts/src/client/mem0.types.ts @@ -125,6 +125,8 @@ export interface Memory { categories?: Array; 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; diff --git a/mem0/memory/main.py b/mem0/memory/main.py index a8b159f14..ac75baa04 100644 --- a/mem0/memory/main.py +++ b/mem0/memory/main.py @@ -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