Manage Content

Memories are mutable: fix them, reorganize them, and prune them.

Update (partial)#

PATCH /v1/memory/collections/notes/memories/{memory_id}
{"text": "corrected text", "importance": 0.9}

Only the fields you send change. Updating text re-embeds the memory so search stays consistent. Read-only keys get 403.

Move between collections#

POST /v1/memory/collections/inbox/memories/{memory_id}/move
{"to_collection": "projects"}

Creates the target collection if needed. The Vault exposes this as drag-and-drop.

Delete#

DELETE /v1/memory/collections/notes/memories/{memory_id}   # one memory (+ its stored files)
DELETE /v1/memory/collections/{name}                       # a whole collection

Deleting a memory also removes its files from object storage.

Semantic forget#

POST /v1/memory/collections/notes/forget
{"query": "everything about project Icarus", "min_score": 0.5, "limit": 10}

Deletes the memories that semantically match the query above min_score — useful for "forget what I said about X" without knowing ids. Start with a high min_score; this is destructive.

Bulk add#

POST /v1/memory/collections/notes/memories/bulk
[{"text": "…", "container_tag": "user-1", "metadata": {"k": "v"}},
 {"text": "…"}]                           # up to 100 per call, one embed batch

Each item takes the same fields as a single create (text plus optional importance, category, source, metadata, container_tag) and returns {"created", "ids"}. The SDKs' add_many / addMany chunk larger lists to the 100-per-call cap for you.

Automatic pruning also exists: remember-extracted facts can carry an expiry and are swept hourly, and superseded facts leave search on their own — see Graph Memory.

PreviousSearch NextOverview