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.jsonpins each working folder to its own project, so client A’s facts never surface in client B’s session. See 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_deletefrom other roles rather than relying on convention. See the 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_idso memories attribute to the right end user. - Set
infer: falseonly 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.
Common Mistakes
Next Steps
Memories Overview
Extraction, retrieval, traces, and conflicts in depth
Scenarios
See these practices applied end to end