Sessions and memory are how OpenClaw maintains conversation context across messages. A session is automatically created when a user starts a conversation, tracking message history, the active agent, and metadata. Memory goes deeper -- it is the persistent knowledge an agent retains across sessions, stored in MEMORY.md and managed through configurable compaction and flushing strategies. Understanding the difference between session-scoped context and persistent memory is essential for building agents that feel coherent over time.
Master openclaw sessions & memory
Take the Introduction to OpenClaw course with hands-on lessons and challenges.
The assistant agent keeps 100 messages of context per session, allowing it to reference earlier parts of the conversation. The alerter agent has memory disabled because each alert is independent -- there is no value in remembering previous alerts during a new one.
MEMORY.md lives in the agent's workspace directory. Its contents are injected into every conversation, so the agent always knows the user's preferences and project context. Keep it concise -- every line costs tokens on every message. Organize by topic and include dates for time-sensitive decisions.
Sessions can be inspected and managed via the CLI. The list command shows all active sessions for an agent. The view command shows the full message history. Export is useful for debugging or creating training data from real conversations.
Session scoping is strict: user + channel + agent = unique session. This isolation is a feature, not a limitation. It prevents accidental context leakage between channels and ensures each agent only sees conversations meant for it.
When the context reaches 80% of the token limit (threshold: 0.8), compaction kicks in. It summarizes older messages while preserving the 20 most recent ones (preserveRecent). Before compaction runs, the flush trigger writes important facts from the about-to-be-compacted messages into MEMORY.md, ensuring key information survives the summarization.
Assuming sessions are shared across channels -- expecting a WhatsApp conversation to be visible when the same user messages on Discord
Sessions are scoped to user + channel + agent. If a customer starts on WhatsApp and switches to Discord, they get a new session. Design your support workflow to account for this.
Filling MEMORY.md with low-value information like greetings or casual conversation details
MEMORY.md content is injected into every conversation, costing tokens on every message. Only store high-value persistent facts: user preferences, project context, key decisions. Treat it like expensive real estate.
Setting maxMessages too high without compaction, causing the context window to overflow and older messages to be silently dropped
Enable context compaction for agents with high maxMessages. Compaction summarizes older messages instead of dropping them, preserving key information while keeping the context within limits.
Disabling memory for conversational agents, causing them to forget the entire conversation after each message
Memory should be enabled for any agent that has multi-turn conversations. Only disable it for stateless agents that handle one-off commands (alerts, deployments, health checks).
Sessions track conversation state scoped to user + channel + agent, while MEMORY.md provides persistent knowledge that survives across sessions. Configure maxMessages based on how much context the agent needs, enable compaction to handle long conversations gracefully, and use pre-compaction flush to preserve important facts. Keep MEMORY.md concise with high-value information only. Disable memory for stateless agents and enable it with compaction for conversational ones.
Interactive lessons and challenges on Stanza, practice in VS Code, Cursor, or the web.
Interactive lessons and challenges, right in your code editor.
Check the free courses. No credit card.