Skip to main content

Overview

Memories are the heart of MemoryLake: structured, durable facts distilled from your conversations and documents. Unlike a chat log (noisy, unbounded) or a document chunk (raw text), a memory is an extracted statement worth keeping — deduplicated, searchable, traceable to its source, and checked for consistency.

Where Memories Come From

Conversations

Playground chats and agent sessions are analyzed automatically — durable facts are extracted, merged with what’s already known, and stored. Transcripts stay transcripts; facts become memories.

Documents

Uploaded files are parsed and indexed; key content becomes retrievable memory alongside conversational facts.

Explicit capture

Store a memory deliberately — via the API (add memory), agent tools (memory_store), or by telling the assistant “remember this”.

Agent auto-capture

Connected agents (OpenClaw and friends) report conversation turns in the background; the server decides what to store, update, or merge.

What Makes a Memory Trustworthy

Source Traces

Every memory keeps a trace back to its origin — the conversation turn or document it was extracted from. Open any memory in the console and check its Source Trace tab, or fetch it via the trace API. When an assistant asserts something, you can always answer “how do you know that?”

Conflict Detection

When a new memory contradicts an existing one — a moved deadline, a changed policy, a corrected fact — MemoryLake doesn’t silently keep both or overwrite blindly. It raises a conflict:
  1. The conflicting pair appears in the project’s Conflicts tab
  2. A reviewer (anyone with the resolve permission) picks what’s true
  3. Memory stays current, and the resolution is deliberate rather than accidental
Conflicts are also exposed via API, and agent tools surface unresolved conflicts alongside retrieval results so assistants can flag uncertainty instead of asserting stale facts.

Deduplication & Merging

Repeating yourself doesn’t create ten copies of the same fact — extraction merges new information into existing memories where they overlap, and updates them when details change.

Retrieving Memories

  • Console: browse and search in the Memories page (workspace-wide) or a project’s Memories tab — including a word-frequency visualization for a quick sense of what a project knows
  • Semantic search: hybrid keyword + embedding retrieval, scoped to a project or workspace — the same engine behind the Playground, agent tools, and the search API
  • Automatic recall: connected assistants retrieve relevant memories before answering — you don’t query anything by hand

Managing Memories

Browse & Inspect

The Memories views support search, filtering, pagination, and bulk selection. Click any memory for details: full content, metadata, and source trace.

Edit

Open a memory and edit its content when a fact needs refinement. Edits take effect immediately in future retrieval.

Forget (Delete)

Forgetting a memory is permanent — it is removed from all future retrieval for every connected assistant and API client.
Delete from the memory’s action menu (or the forget API). This is also your “right to be forgotten” mechanism when building user-facing products.

Individual and Organizational Memory

The same machinery serves two different kinds of knowledge: Both flow through extraction → trace → conflict-checking → retrieval; the difference is scope and governance. See the Personal AI Memory and Team Knowledge Base scenarios.

Working with Memories Programmatically

All paths are relative to https://app.memorylake.ai/openapi/memorylake. Start with Core Memory Operations for the end-to-end flow.
Earlier project-scoped api/v1 and api/v2 memory endpoints remain available for existing integrations and are documented under Deprecated in the API reference. New integrations should use the v3 paths above.

Next Steps

Best Practices

Get better memories out of conversations, documents, and agents

Integrations

Bring memory recall into your agents and apps

Memories API

Manage memories programmatically