Why Memory Matters More Than You Think
Most chatbots forget everything. You tell them your name, your project, your preferences, and the next time you talk to them it's a blank slate. This is fine for asking "what's the weather" but it's terrible for a work assistant. An assistant that can't remember what you talked about yesterday isn't an assistant. It's a search box with a personality.
OpenClaw has a real memory system. It's not perfect, and it has limitations you need to understand, but it's meaningfully better than the stateless chatbot model. Here's how it works, specifically when running in Slack.
The Three Layers of Memory
OpenClaw's memory works in three layers, each with different persistence and scope.
Layer 1: Thread Context (Short-term)
Every Slack thread is its own conversation. When you start a thread with the bot, it reads all the messages in that thread as context. This is the simplest form of memory: the bot knows what you just said because it can see the thread.
The catch is context window limits. OpenClaw uses an LLM (usually Claude) to process messages, and LLMs have a maximum context window. As of March 2026, Claude's context window is 200K tokens, which is roughly 150,000 words. That sounds like a lot, and for most threads it is. But if you're in a thread with 500+ messages (like a long-running incident thread), the oldest messages start falling off.
This is where context compaction kicks in.
Layer 2: Context Compaction (Medium-term)
When a thread gets too long for the context window, OpenClaw doesn't just drop old messages. It compacts them. The agent summarizes older portions of the conversation into a condensed format, preserving key facts, decisions, and context while discarding the verbatim back-and-forth.
Think of it like taking notes. You don't need the full transcript of yesterday's meeting; you need the decisions and action items. Compaction does the same thing. A 300-message thread might get compacted into a 2,000-word summary of the key points, plus the last 50 messages in full.
This happens automatically. You don't need to configure it. But you should know that it's happening because compacted context can lose nuance. If someone said something important 200 messages ago and it was a subtle point (not a clear decision or action item), compaction might not preserve it. For important details you want the bot to always remember, use Layer 3.
Layer 3: MEMORY.md (Long-term)
MEMORY.md is OpenClaw's long-term memory. It's a markdown file that the agent reads at the start of every conversation and can write to at any time. Think of it as the bot's notebook.
You can seed it manually:
# MEMORY.md
## Team Context
- We're a 15-person engineering team at Acme Corp
- Our main product is an e-commerce platform (Rails + React)
- Sprint cycles are 2 weeks, starting Mondays
- Team lead is Sarah (@sarah)
## Key Decisions
- 2026-02-15: Decided to migrate from Heroku to AWS ECS
- 2026-02-28: Chose Datadog over New Relic for monitoring
- 2026-03-05: Froze new feature work until migration complete
## Preferences
- Status updates go in #engineering-updates
- Bug reports go in #bugs, not DMs
- Sarah prefers bullet points over long paragraphsOr you can tell the agent to remember things in Slack:
@openclaw remember: our deployment window is Tuesdays and Thursdays, 2-4pm ESTThe agent adds that to MEMORY.md. Next time anyone asks about deployments, the bot knows the window without being told again.
How Slack Threading Interacts with Memory
Slack's threading model is both a blessing and a limitation for OpenClaw's memory.
The blessing: threads create natural conversation boundaries. Each thread is a focused topic, which means the bot's context is relevant and not polluted by unrelated messages from the channel.
The limitation: the bot doesn't carry context between threads by default. If you have a conversation in one thread about a project plan, then start a new thread asking a related question, the bot doesn't automatically know about the first thread. It has to rely on MEMORY.md or you need to reference the earlier thread explicitly.
This is actually different from how many people expect AI assistants to work. In ChatGPT or Claude's web interface, you can start new conversations and the AI remembers (somewhat) what you've discussed before. In Slack, each thread is its own island unless MEMORY.md bridges them.
Practical advice: if your team is working on a long-running project, tell the bot to remember key details in MEMORY.md as they come up. That way, any team member in any thread gets the benefit of that context.
Memory and Channel Messages (Non-threaded)
What about messages that aren't in threads? When someone @mentions the bot in a channel without starting a thread, the bot reads a window of recent channel messages as context. By default, that window is the last 20 messages or 10 minutes, whichever is less.
You can configure this window:
# In your OpenClaw config
SLACK_CHANNEL_CONTEXT_MESSAGES=50
SLACK_CHANNEL_CONTEXT_MINUTES=30Bigger windows give more context but use more tokens (which means higher LLM costs). For most teams, the default is fine. Bump it up if your channels are quiet and conversations are spread out; dial it back if your channels are firehoses and the context is mostly noise.
Memory Management Tips
Keep MEMORY.md organized. Over time, it grows. The bot adds to it, you add to it, and eventually it's a sprawling mess. Review it monthly. Delete outdated information. Keep it under 5,000 words; beyond that, the bot spends too many tokens reading its own notes. For more tips, check our article on using OpenClaw memory features in Slack.
Use sections. Structure MEMORY.md with clear headings. The agent is better at retrieving information when it's organized than when it's a flat list of random facts.
Be explicit about what to forget. You can tell the bot:
@openclaw forget: the deployment window has changed, remove the old oneThis removes outdated information from MEMORY.md. Without this, old and new facts can contradict each other, and the bot might use the wrong one.
Different channels, same memory. MEMORY.md is shared across all channels the bot is in. This is usually what you want (team context should be universal), but be aware of it. If you tell the bot something in #engineering, it'll know it in #sales too. If you're running agents with different roles, use the multi-agent approach with separate memory files per agent; see our multi-agent guide.
Context Overflow and What Happens
Context overflow is when the total context (thread messages + compacted history + MEMORY.md + skill instructions + system prompt) exceeds the LLM's context window. When this happens, OpenClaw has to drop something. The priority order is:
- System prompt (never dropped)
- SOUL.md (never dropped)
- MEMORY.md (trimmed if necessary, starting from the bottom)
- Recent messages (kept)
- Compacted history (trimmed)
- Skill instructions for inactive skills (dropped first)
In practice, context overflow is rare with Claude's 200K window. But if you have a very large MEMORY.md, a very long thread, and multiple active skills, it can happen. The bot will still respond, but it might miss context from earlier in the conversation.
If you're hitting overflow regularly, it usually means MEMORY.md needs pruning or you need to split your agent into multiple specialized agents with smaller memory footprints.
SlackClaw's Memory Advantages
SlackClaw runs the same memory system as self-hosted OpenClaw, with a couple of additions. First, the dashboard lets you view and edit MEMORY.md through a web interface instead of SSHing into a server. Second, we run automatic memory optimization that periodically consolidates and prunes MEMORY.md to keep it efficient. Third, memory is backed up daily, so you can roll back if something gets corrupted.
These aren't magic. They're ops tasks that you'd have to do manually on a self-hosted instance. SlackClaw just automates them. Check the security page for details on how memory data is stored and isolated.