Integrations playbook

Why your OpenClaw agent keeps “forgetting” (and how Supermemory fixes it)

If your “memory” is a pile of transcript chunks, your agent will feel inconsistent after week two. This playbook explains why tool-first memory makes OpenClaw feel like it forgets, and how Supermemory fixes it with auto-recall + auto-capture, user profiles, knowledge updates, and automatic forgetting.

TL;DR (what you are actually buying with “memory”)

In production, “memory” is not storage. It is: the ability to carry user identity, preferences, and evolving facts across conversations, across channels, and across time.

OpenClaw + Supermemory gets you there with auto-recall (inject the right context before the model answers), auto-capture (extract and store durable facts after the model answers), and user profiles (a persistent “about me” that stays up to date).

You get continuity across WhatsApp, Telegram, Discord, Slack, and more (one agent, one memory layer)
You stop treating “memory” as a vector search problem and start treating it as a lifecycle problem
You can isolate contexts using container tags (work vs personal vs bookmarks)
You keep an escape hatch: manual /remember and /recall when you want explicit control

What OpenClaw + Supermemory does (and why it matters)

OpenClaw is the multi-platform messaging gateway. Supermemory is the memory backend.

The integration is valuable when you want your agent to behave like a system with continuity, not like a stateless chat window that occasionally “finds a similar sentence.”

Customer support: remembers past issues and prefers the same troubleshooting style
Founder ops: remembers decisions, budgets, and “what we tried last time”
Personal assistant: remembers preferences without re-asking every week
Team workflows: remembers operating rules and constraints across channels

Why OpenClaw keeps “forgetting” (even when memory exists)

Most “forgetting” is not a model intelligence problem. It is an architecture problem: memory is treated like a tool the agent might or might not use, instead of a hook that reliably injects context every run.

If the model is not consistently calling memory tools, the system will feel stateless. If it only fetches context when prompted, it will miss basic preferences and recently-updated facts.

The core fix

Memory should be reliable context injection (hooks), not a best-effort tool call.

Tool-first memory is optional: the agent must decide to call it
Tool calls add latency and token overhead, so they often get skipped
Write-side memory is also tool-driven, so “remembering” a new fact is not automatic
If you do not handle knowledge updates, the system accumulates redundancy and contradictions
If you do not forget, memory becomes stale noise and gets less useful over time

How OpenClaw memory works today (files + read-side tools)

OpenClaw’s default memory model is file-based with a curated long-term file plus daily append-only logs.

It works, but it is easy to end up in a state where memory is technically present yet behavior still feels inconsistent, because recall depends on tools being called.

Implication

In group chats, long-term curated memory may not load, so you must plan for “lower recall” unless you explicitly route memory elsewhere.

Daily logs: `memory/YYYY-MM-DD.md` append-only notes; commonly loaded for “today + yesterday” at session start
Curated memory: `MEMORY.md` durable facts, preferences, and decisions; typically loaded only in private/DM sessions (not group chats) for privacy
`memory_search`: semantic search over memory files that returns scored snippets
`memory_get`: fetch specific lines after you locate them via search

Install and setup (copy/paste)

The Supermemory plugin is installed as an OpenClaw plugin, then configured with your Supermemory API key.

Your Supermemory API key starts with `sm_` (from the Supermemory console).

Requirement

This integration requires the Supermemory Pro plan.

1) Install the plugin

openclaw plugins install @supermemory/openclaw-supermemory

2) Run setup (paste your sm_ key when prompted)

openclaw supermemory setup

3) Verify it is connected

openclaw supermemory status

Advanced setup: container tags and routing rules

By default, session memories across every channel are stored under a single root-level container tag.

If you want separation (work vs personal, or “bookmarks” vs writable memory), enable custom container tags and add simple routing instructions for your agent.

Design principle

If memory can cross-contaminate workflows, it will. Separate containers early, while memory is still small.

Each custom container needs a tag and a description (the description is how the AI understands what belongs there)
Per-channel separation is not automatic yet; you can approximate it with custom instructions like “When on Slack use work; when on WhatsApp use personal”
Make read-only containers for sources you never want the agent to mutate (for example: bookmarks)
You can change settings later by telling the agent what to add or change

Configure options interactively (recommended if you want containers)

openclaw supermemory setup-advanced

Example configuration intent (what you want the agent to do)

- Auto recall: true
- Auto capture: true
- Enable custom container tags: true
- Custom containers:
  - work: Work-related memories from Slack and Gmail
  - personal: Personal memories from Telegram and WhatsApp
- Custom instructions: When on Slack or Gmail, use the work container.
  When on Telegram or WhatsApp, use the personal container.

How it works: auto-recall + auto-capture

This is the core loop that makes the system feel consistent: it loads the right context before generating, and it commits durable updates after generating.

You want both. Recall without capture drifts. Capture without recall becomes a junk drawer.

Auto-Recall: before every AI turn, Supermemory is queried for relevant memories and the user profile, then injected as context
Auto-Capture: after every AI turn, the conversation exchange is sent to Supermemory for extraction and long-term storage
Supermemory handles deduplication and profile building so you do not store the same preference 20 times

What Supermemory changes (hooks, updates, and forgetting)

The practical difference is that memory becomes implicit. Saves happen in the background. Recall happens consistently. And “new facts” can update old ones instead of duplicating them forever.

This is also why memory stops feeling like “search” and starts feeling like “personalization”: the system can understand temporality (what is current), resolve contradictions, and decay irrelevant information.

Best of both worlds

In practice you want both: RAG for knowledge base retrieval, and memory for personalized context. Supermemory is designed to run both together so each query can use the right context.

Implicit saves: the plugin can capture without you asking the agent to call a “save memory” tool
Knowledge updates: newer facts can update older facts (preserve history, return the latest)
Temporal reasoning: what was true last month is not treated as truth today
Automatic forgetting: temporary facts (example: “I have an exam tomorrow”) can expire so noise does not become permanent memory

Day-to-day controls: AI tools, slash commands, CLI

The plugin exposes tools to the agent, plus explicit commands to you. This matters in production because you need visibility and override paths when something feels wrong.

Your “memory system” is only real if you can inspect, search, and delete.

AI tools: `supermemory_store`, `supermemory_search`, `supermemory_forget`, `supermemory_profile`
Slash commands: `/remember [text]` and `/recall [query]`
CLI: inspect config, search memory, view profile, and wipe memory (with confirmation)

Useful CLI commands

openclaw supermemory status
openclaw supermemory profile
openclaw supermemory search <query>
openclaw supermemory wipe

Why memory is not a key-value store

A key-value store is great when you already know the key and you want the latest value.

Agent memory fails if you reduce it to KV because retrieval is usually implicit, facts change over time, and you need “what is relevant right now” rather than “what key do I look up.”

Rule of thumb

KV stores facts. Memory systems manage facts over time.

Users do not ask for `preferred_response_format`; they ask “can you summarize this?”
Preferences and facts evolve (what used to be true can become false)
You need conflict handling (new info can update older info)
You need relevance, not just retrieval

Why memory is not “just RAG”

RAG retrieves document chunks. It is stateless, and it returns the same results for everyone. That is exactly what you want for a knowledge base.

Memory is different: it extracts and tracks facts about users over time. It needs temporality (what is current), relationships (what caused what), and state (what the user believes now).

When you treat memory as “store chats in a vector DB and semantic search,” you eventually retrieve the wrong truth because similarity is not the same as recency or validity.

RAG: raw knowledge retrieval (docs, PDFs, web pages)
Memory: user facts that evolve (“I just moved to SF” supersedes “I live in NYC”)
Similarity search can surface an old preference that was later reversed
Memory requires “latest vs historical” semantics, not just nearest neighbor
Memory needs structure: what changed, what still holds, what was inferred
In practice you want both together: knowledge base retrieval plus personalized context in the same query

Graph memory: updates, extends, derives

Supermemory models memory as a knowledge graph where memories connect to other memories.

This is the missing layer in transcript-only approaches: it allows the system to preserve history while still returning current information.

Practical benefit

You get “current answer, preserved history” instead of “whatever text was most similar.”

Updates: new information contradicts and replaces older information (while preserving the older memory as history)
Extends: new information adds detail without replacing older information
Derives: inferred information from patterns across interactions

User profiles: a persistent “about me” that stays up to date

Traditional memory systems rely entirely on search. Profiles reduce that overhead by giving you a comprehensive baseline context in one call.

Think of profiles as the foundation, and search as the precision tool you use when you need specifics.

Profiles are automatically maintained collections of facts about your users
Profiles update as users interact with your system
Profiles separate stable long-term facts from dynamic “current project” context
Profiles reduce the number of retrieval calls you need in normal conversations

Benchmarks (directional, but useful)

Public benchmarks are not gospel, but they are a good forcing function: you should measure memory systems on update handling, temporal correctness, and recall consistency.

One reported evaluation compares filesystem-style memory, tool-driven RAG-style memory, and Supermemory’s hook-based approach. Use it as a starting point, then run your own eval against your workflows.

Do this for real

If memory affects revenue or trust, build a small evaluation set and track it weekly. Memory regressions are common once you add more workflows and channels.

Filesystem memory (example: “Claude code memory” style): 54.2%
Tool-driven RAG memory (example: OpenClaw memory tool, assuming it is called): 58.3%
Supermemory (automatic, implicit): 85.9%

A sane production baseline (start here)

If you want this to work past the demo, keep your first memory setup boring: small number of containers, simple routing rules, and explicit deletion paths.

Then you can extend it safely once you trust the recall and capture loop.

Start with one container tag, then add `work` and `personal` once the first week feels stable
Add a read-only container for any “source” content you do not want mutated
Write a single routing rule per channel, and keep the rule short
Run a weekly memory review: prune contradictions, tighten instructions, and delete noise
Decide up front what “forget” means for your use case (and use wipe sparingly)

How Clawdguy helps (when you want to stop babysitting the runtime)

Memory systems are only as good as the runtime they run on. If your gateway is flaky, slow, or frequently reset, you will blame “memory” for infrastructure failures.

Clawdguy gives you managed OpenClaw hosting so you can focus on workflows, guardrails, and memory quality instead of servers.

Dedicated infrastructure with root access
Managed provisioning, updates, and recovery controls
A stable baseline for measuring memory and workflow changes