End-of-session memory patterns: what your OpenClaw agent should remember (and forget)
Your agent just wrapped a 45-minute session. The user asked about three topics, changed their mind twice, corrected a factual error, and mentioned they’re traveling next week. What should your agent store?
Most OpenClaw agents either store everything (expensive, noisy) or store nothing (amnesia). There’s a middle ground, and it’s not complicated once you have a framework.
What actually matters after a session
Think about what you’d remember after a conversation with a coworker. You wouldn’t memorize every word. You’d walk away with: what was decided, what you got wrong, what they care about, and what happens next.
That’s your template.
Store: decisions and outcomes
If the user made a choice, keep it.
memoclaw store --text "Decided to use PostgreSQL instead of SQLite for the project database" --importance 0.7 --tags decision,tech-stack --namespace project-alpha
Store: corrections
When someone corrects your agent, that’s high-value information. The agent got something wrong and should never repeat the mistake.
memoclaw store --text "Correction: user's company is based in Berlin, not Munich. I got this wrong on March 10." --importance 0.9 --tags correction,user-info
Corrections get high importance scores. An agent that keeps making the same mistake after being corrected is worse than one with no memory at all.
Store: preferences and personal info
“I prefer TypeScript over Python.” “Don’t schedule anything before 10 AM.” “I’m vegetarian.” These are the things that make an agent feel like it knows you.
memoclaw store --text "User prefers morning meetings after 10 AM, never before" --importance 0.6 --tags preference,scheduling
Store: action items
If something needs follow-up, store it.
memoclaw store --text "TODO: follow up on PR review for auth module by Thursday" --importance 0.7 --tags action-item,project-alpha
Skip: transient context
“The build is currently failing.” “User is on a call right now.” These are true now but useless tomorrow. Keep them in session state (AGENTS.md, daily memory files) instead.
Skip: facts already stored
If your agent already knows “user prefers dark mode,” don’t store it again. Duplicates waste space and muddy recall.
Before storing, check:
memoclaw recall --text "user dark mode preference" --namespace user-preferences --limit 3
Already there? Skip it.
Skip: raw conversation
Don’t store the full chat transcript. That’s logging, not memory. MemoClaw memories cap at 8192 characters per entry, and a transcript will hit that fast while being mostly noise.
A repeatable pattern for AGENTS.md
Add this block to your agent’s AGENTS.md. It’s not code the agent executes automatically — it’s instructions the agent follows when wrapping up a session.
## End-of-session memory routine
Before closing a session, review the conversation and store memories for:
1. **Decisions made** — what was chosen and why (importance: 0.6-0.8)
2. **Corrections received** — anything I got wrong (importance: 0.9)
3. **New preferences** — things the user likes/dislikes (importance: 0.5-0.7)
4. **Personal facts** — locations, roles, relationships (importance: 0.6)
5. **Action items** — follow-ups needed (importance: 0.7)
Do NOT store:
- Transient state (current weather, ongoing meetings)
- Facts already in memory (recall first, check for duplicates)
- Raw conversation text
- Anything in SOUL.md or system prompt already
Use tags consistently: decision, correction, preference, personal, action-item
Use the appropriate namespace for the topic.
Importance scores
Here’s the scale I use:
- 0.9-1.0 — Corrections, safety info, things the agent must never get wrong
- 0.7-0.8 — Decisions, action items, things that affect future behavior
- 0.5-0.6 — Preferences, personal info, nice-to-know context
- 0.1-0.4 — Casual mentions, minor details, low-confidence info
Don’t overthink it. The goal is rough ordering, not precision. An agent that scores corrections at 0.9 and trivia at 0.3 will recall better than one that scores everything at 0.5.
The extract shortcut
If you don’t want to manually pick what to store, the extract endpoint does it for you. Pass it a block of text and it pulls out structured memories.
memoclaw extract --text "We decided to switch from REST to GraphQL. Also, remind me to update the API docs by Friday. Oh, and I prefer the blue theme, not the green one." --namespace project-alpha
This costs $0.01 per call (uses GPT-4o-mini under the hood), but it saves time when sessions cover a lot of ground. It’ll pull out the GraphQL decision, the docs reminder, and the theme preference as separate memories with reasonable importance scores.
When to consolidate
After a few weeks of storing session memories, you’ll accumulate overlapping entries. Maybe three memories all say slightly different things about the user’s tech stack preferences.
Run consolidate periodically:
memoclaw consolidate --namespace project-alpha
This merges related memories and resolves contradictions. Once a week or once a month is fine depending on how active the agent is.
The cost math
With the free tier (100 calls), a careful agent can run for weeks. If you store 3-5 memories per session and recall once at session start, that’s about 6 calls per session — roughly 16 sessions before hitting the free limit.
After that, storing costs $0.005 and recall costs $0.005. A session that stores 4 memories and does 1 recall runs $0.025. About 40 sessions per dollar.
Wasting calls on duplicate recalls and junk memories is what drives costs up. The patterns here keep usage efficient.
Start simple
You don’t need a perfect memory system on day one. Start with the AGENTS.md block above. Let your agent store decisions and corrections for a week. Check what’s in there:
memoclaw list --namespace default --limit 20
Adjust importance scores based on what’s actually useful during recall. Add namespaces when the default gets crowded. Consolidate when things get stale.
Memory is a habit, not a feature. Build it gradually.