In this chapter, you will store a preference that survives across sessions and discover commands that bypass the model entirely.
By the end, you should be able to explain the difference between MEMORY.md (curated long-term memory that loads every session) and the memory/ directory (daily logs where only today and yesterday load automatically). You will also learn slash commands: direct instructions the gateway intercepts before the model sees them, costing zero tokens and responding instantly.
The key habit this chapter teaches: verify on disk, not just in chat. Verbal confirmation is not proof of a file write.
James opened WhatsApp the next morning and sent: "What formatting preferences do I have for summaries?"
The agent responded with a generic list of formatting best practices. Nothing about the bullet-point format James had asked for yesterday. Nothing about the 100-word limit.
"It forgot everything I told it," James said.
Emma set her coffee down. "Session memory fades when the conversation ends. The workspace files you edited in Module 9.1, Chapter 4 persist because they are files on disk. But anything you said in conversation? Gone when the session closes."
"So I have to re-explain my preferences every morning?" James asked.
"No," Emma said. "You tell it to save them to memory. There is a difference between saying something in a conversation and writing it to a file." She stood up. "Send it this: 'Save in memory: I prefer all summaries under 100 words as bullet points.' Then close the conversation, start a new one, and ask if it remembers." She paused at the door. "When I get back, show me WHERE it stored the memory and PROVE it persisted. Not a chat screenshot. The actual file on disk." She picked up her coffee and left.
You are doing exactly what James is doing. Your agent's session memory fades, and you need preferences that survive across conversations.
Send this to your agent on WhatsApp:
Start your message with "Save in memory:" to trigger an actual file write. If you use "Remember this:" instead, the agent may respond with "Got it, noted!" without actually writing anything to disk. The verbal confirmation is not proof.
Open a terminal and read the file:
You should see your preference stored on disk. The output will look something like this:
If the file does not exist or does not contain your preference, the agent acknowledged your request without actually saving it. Send the request again with "Save in memory:" at the start.
Open the OpenClaw dashboard and look at your recent chat. You will see a tool badge next to the agent's response indicating a file write operation. This badge is visual proof the agent wrote to disk.
Verbal Confirmation Is Not Enough
If your agent says "Got it" or "I've noted that" but you do not see a tool badge for a file write, the preference was NOT saved to disk. The agent confirmed your intent without acting on it. Send the request again with "Save in memory:" at the start and check for the tool badge.
Close the conversation. Start a new one. Then ask:
The agent recalls your bullet-point preference without you repeating it. It did not re-read your old conversation. It read from the memory file that loaded when the session started.
Now that you have experienced it, here is what is happening under the hood. Your agent has two memory locations in ~/.openclaw/workspace/:
You just wrote to this file. It loads at the start of every session, so the agent always has access to your stored preferences.
The memory/ directory holds daily logs named by date. The agent writes session notes and observations here automatically. Check yours:
You will see one file per day your agent has been active.
Today's log and yesterday's log load automatically. Everything older stays on disk but does not load at session start. When the agent needs something from an older log, it uses memory_search: hybrid retrieval that combines vector similarity (matching meaning) with keyword matching (matching exact terms). This finds relevant notes even when the wording in the stored note differs from your question.
The design keeps context small. Loading every daily log since installation would burn tokens on irrelevant history. The agent loads recent context automatically and searches older context on demand.
When a conversation runs long, the gateway compacts older turns into a summary to free context space. Before compacting, the agent is automatically reminded to save anything important to memory files. This is why persistent memory matters: session context can be summarized away at any time, but MEMORY.md and daily logs survive on disk. You can also trigger compaction manually with /compact if your conversation feels sluggish.
Your agent responds to natural language, but it also accepts direct commands. Send this:
Notice the response: instant, no "thinking" indicator, no tool badge. The gateway intercepted /help and returned the result directly. The model never processed your message. No tokens spent, no inference time.
Now send:
You see diagnostics: your current model, session state, and quota information. Again, instant. The gateway knows this information without asking the model.
Ask the same thing in natural language:
The response is slower. You may see a thinking indicator or tool badge. The model had to interpret your question, reason about it, and compose a response. The speed difference you just experienced is the proof: slash commands bypass the model entirely.
The /commands list grows as you enable plugins. After you install your first plugin in Module 9.1, Chapter 6, run /commands again to see what it added.
Tell your agent to save five things about you. Use "Save in memory:" for each one: your role, your preferred communication style, your timezone, a current project, and one thing the agent should never do. Close the conversation and start a new one. Ask "What do you know about me?"
Then verify with:
Compare what the agent recalls versus what is actually on disk. Are they the same?
What you are learning: Persistent memory is how you train an agent over time. Each "Save in memory:" adds to MEMORY.md, building a profile that loads on every session start. The terminal check confirms the agent is not fabricating recall.
Open the dashboard and scroll through your recent chat history. Count the tool badges. Which of your messages triggered file writes? Which got verbal acknowledgment only?
Send a message that starts with "Remember this: my favorite color is blue." Then send another: "Save in memory: my preferred meeting length is 25 minutes." Check the dashboard for tool badges on each. Did both write to disk, or did only one?
What you are learning: The dashboard is your verification layer. Tool badges are evidence of action. Verbal confirmation without a tool badge means the agent understood your intent but may not have acted on it.
Send /status. Then ask "What is your current status?" in natural language. Time both responses. Which was faster? Which showed a tool badge or thinking indicator?
For a bonus, try switching models mid-conversation:
Ask a question. Then switch back:
What you are learning: Slash commands are gateway-intercepted. They cost zero tokens and respond instantly. Natural language goes through the full model pipeline. The /model command lets you switch inference providers without restarting your session.
MEMORY.md is your curated notebook. It loads at the start of every session. Store preferences, facts, and key decisions here. Keep it short: a long MEMORY.md pushes entries past the model's attention window.
memory/YYYY-MM-DD.md files are daily journal logs. Today's and yesterday's load automatically. Everything older stays on disk and is found through memory_search (hybrid retrieval combining vector similarity and keyword matching).
When you say "Save in memory," check the dashboard for a tool badge confirming a file write. Then check the file on disk with cat ~/.openclaw/workspace/MEMORY.md. Verbal confirmation without a tool badge means the agent understood your intent but may not have acted on it.
Commands like /help, /status, and /model are intercepted by the gateway before the model sees them. Zero tokens spent, instant response. Natural language questions about the same information go through the full model pipeline. Use commands for control; use natural language for reasoning.
When conversations run long, the gateway compacts older turns into summaries. Before compacting, the agent saves important context to memory files. This is why persistent memory matters: session context can be summarized away, but MEMORY.md and daily logs survive on disk.
When Emma came back, James had the terminal and the dashboard open side by side. He pointed at the terminal first.
"MEMORY.md has six entries. My name, timezone, summary format, report style, and two things it decided to remember on its own from yesterday's conversation." He tapped the dashboard. "Every entry has a matching tool badge in the chat. That is how I know the writes actually happened."
"And the commands?" Emma asked.
James switched to WhatsApp. "I sent /status and then asked the same question in plain English. /status came back in under a second. The natural language version took three seconds and showed a thinking indicator." He paused. "At my old warehouse job, we had two systems: the employee handbook that everyone got on day one, and the daily shift log the floor manager kept. The handbook had the big picture rules. The shift log was 'what happened today.' MEMORY.md is the handbook. The daily logs are the shift log. And if you needed to find something from a shift three months ago, you searched the archive. You did not read every log since January."
Emma tilted her head. "That actually maps. The handbook loads every session. The shift log loads for today and yesterday. Everything older goes through search."
"And slash commands?" Emma asked.
"The walkie-talkie," James said. "Direct channel. No interpretation needed. You do not ask the walkie-talkie to think about your request."
Emma nodded. Then she looked at MEMORY.md again. "One thing. I once crammed about two hundred entries into MEMORY.md for a project. Preferences, facts, project notes, meeting summaries. The agent started ignoring entries near the bottom because the file was so long it pushed past the useful part of the context window. I had to go back and curate it down to the thirty entries that actually mattered." She closed the terminal. "Keep MEMORY.md short. It is a curated notebook, not a dump file."
James opened MEMORY.md in his editor. "Six entries. Noted."
"What if I outgrow this setup?" James asked. "Hundreds of daily logs, and the search gets slow, or I want the agent to build a profile of me automatically instead of me saying 'save in memory' every time?"
Emma pulled up the memory docs. "The builtin engine you are using now is SQLite with vector and keyword search. It handles most personal setups. When you outgrow it, there are two alternatives worth reading about: QMD is a local search sidecar that adds reranking and can index entire project directories, not just your workspace. Honcho is an AI-native memory service that builds user profiles automatically from conversations and works across multiple agents." She closed the tab. "You do not need either today. But when you hit the limits of the builtin engine, those are the two upgrades. Read the docs when you are ready."
"Your agent remembers now," Emma said. "Next question is whether it knows enough. You might want it to know financial modeling or legal review. That is what skills and the ecosystem are for."