> ## Documentation Index > Fetch the complete documentation index at: https://docs.memorylake.ai/llms.txt > Use this file to discover all available pages before exploring further. # Memory Best Practices > How to get accurate, useful long-term memory out of conversations, documents, and agents MemoryLake extracts memories automatically — you don't write them by hand. Best practice is therefore less about *authoring* and more about *feeding the system well* and *keeping it honest*. Here's what works. ## Feeding Memory Well ### Say facts explicitly when they matter Extraction is good at picking up clear statements and decisions, and appropriately skips small talk. When something must be remembered, state it plainly: * ✅ *"Remember: the budget cap for Q1 is \$75K, hard limit."* * ✅ *"We decided to use PostgreSQL — better JSON support and the team knows it."* * ⚠️ *"Yeah let's maybe go with the second option I guess"* — ambiguous references extract poorly. Name the thing. ### Include the why, not just the what A decision with rationale is a far more useful memory than a bare conclusion. *"We chose PostgreSQL over MySQL for JSON support and team expertise"* lets a future assistant answer *"why Postgres?"* — not just *"which database?"* ### Upload the source document, don't paraphrase it If knowledge lives in a file, upload the file. Document content is parsed and indexed with higher fidelity than a chat summary of it, and memories extracted from it carry a trace to the actual source. ### Correct out loud When something changes, say so explicitly — *"The launch moved from October 15 to November 1"* — rather than just mentioning the new date in passing. Explicit corrections update or conflict-flag the old memory instead of leaving two versions in play. ## Scoping: the Highest-Leverage Decision Retrieval is scoped to projects. Well-scoped projects mean relevant recall; kitchen-sink projects mean noise. * **One project per context** — per client, per initiative, per life domain. Not one giant "Everything" project. * **Use per-agent config for multi-client work** — the OpenClaw plugin's per-directory `.memorylake/config.json` pins each working folder to its own project, so client A's facts never surface in client B's session. See [Coding Agents](/scenarios/coding-agents). * **Split when retrieval gets noisy** — if answers start citing irrelevant context, your project is probably covering two contexts. Split it. ## Keeping Memory Honest ### Review conflicts promptly Conflicts are memory's immune system — but only if someone resolves them. Check the project's **Conflicts** tab when the assistant seems uncertain about a fact, and after any burst of corrections. In teams, make sure someone holds the resolve permission and owns the habit. ### Audit with traces Before trusting a surprising assertion, open the memory's **Source Trace** — you'll see exactly which conversation or document produced it. This is also the fastest way to debug *why* an assistant believes something wrong: find the memory, trace it, then edit or forget it. ### Prune deliberately * **Edit** memories whose details drifted (titles, numbers, names) * **Forget** memories that are obsolete or should never have been captured — deletion is permanent and takes effect everywhere * Don't over-prune: dedup and merging already handle repetition; delete for *wrongness*, not tidiness ## For Teams * **Establish what belongs in shared memory** — decisions, policies, client facts: yes. Personal working notes: keep in personal space. The workspace boundary is the individual/organizational memory line. * **Assign conflict ownership** — a project without a conflict-resolver accumulates stale facts silently. * **Lean on permissions, not caution** — if only leads should delete memories, remove `mem_delete` from other roles rather than relying on convention. See the [Permission Reference](/features/team-collaboration/permission-reference). ## For Builders (API) * **Send full conversation turns** to add-memory (`infer: true`) and let extraction decide what's durable — pre-filtering usually loses context that improves extraction quality. * **Use `user_id`** so memories attribute to the right end user. * **Set `infer: false`** only when you're storing an already-curated fact verbatim. * **Expose trace and forget to your users** — "why do you know this?" and "forget this" build trust and cover compliance. * **Check conflicts programmatically** if your product asserts facts — see [Conflicts API](/features/memorylake/api-reference/memories/list-memory-conflicts). ## Common Mistakes | ❌ Mistake | ✅ Instead | | ---------------------------------- | --------------------------------------------------------------------- | | One giant project for everything | One project per context; retrieval stays sharp | | Pasting a doc's contents into chat | Upload the document itself | | Correcting facts implicitly | State corrections explicitly so old memory gets updated/conflicted | | Ignoring the Conflicts tab | Review after corrections; assign an owner in teams | | Deleting memories to "clean up" | Edit or forget only what's wrong — merging already handles duplicates | | Trusting a weird assertion blindly | Open its source trace first | ## Next Steps Extraction, retrieval, traces, and conflicts in depth See these practices applied end to end