Building My Second Brain on OpenClaw (Part 7)
Welcome back to another Articles by Victoria, the place where I randomly write things I'm curious about.
At some point in this series, a question started nagging at me.
I had built automations. I had set up content pipelines, calendar reminders, a collab evaluator, and security monitoring. The agent was doing real work. But every new session, it woke up fresh. Well, it had MEMORY.md and daily logs sure, but its knowledge was scattered, flat, and entirely dependent on me to curate.
I had built a second brain that kept forgetting how to think.
Here's the parts in case you need to catch up:
- Part 1: Getting Started with OpenClaw
- Part 2: Connecting Telegram and Google Workspace
- Part 3: Daily Automations and Task Management
- Part 4: Advanced Workflows - RAG, LinkedIn, and Content Generation
- Part 5: Security and Monitoring
- Part 6: System Design and Best Practices
Part 7 is about fixing that. It covers how memory works in OpenClaw, what was missing in my setup before, and how I wired up a proper knowledge layer that actually compounds over time instead of degrading.
What Memory Even Means for an AI Agent
Before I get into the implementation, I want to be clear about what "memory" means in this context, because it means something different than what most people assume.
When you chat with a large language model, you might assume it remembers your past conversations. It does not. Every session starts cold. What feels like memory is usually the system prompt, or a context window that includes your recent messages.
For an agent like OpenClaw that runs continuously, handles multiple sessions, and has real access to your calendar, tasks, and files, this is a problem. Not just a UX inconvenience. A real architectural problem.
If the agent does not know who you are, what your preferences are, what projects matter to you, and what it has already learned, it cannot act on your behalf intelligently. It can only react.
Memory is what separates a reactive assistant from one that genuinely understands your context.
Where Memory Can Live: The Options
There are a few different approaches to agent memory, each with different trade-offs. Here is an honest comparison.
Option 1: In-Context Memory (Conversation History)
The simplest approach. Everything the agent knows is contained in the current conversation window. The model sees the recent messages and uses that as its working memory.
| Dimension | Details |
|---|---|
| How it works | System prompt + recent chat history passed with each request |
| Pros | Zero setup, immediate, no infrastructure needed |
| Cons | Volatile — lost when the session ends or compacts; does not scale; can consume expensive tokens |
| Best for | Short tasks, one-off sessions, quick prototyping |
OpenClaw uses this for real-time conversation context within a session. But it is not durable.
Source: Anthropic: Memory and context in AI agents
Option 2: Flat File Memory (Markdown files)
This is what most OpenClaw setups, including mine before Part 7, rely on. You maintain markdown files like MEMORY.md, USER.md, TOOLS.md, and the agent loads them at session start.
| Dimension | Details |
|---|---|
| How it works | Files injected into system prompt or loaded on demand via read tool |
| Pros | Human-readable, version-controllable, easy to audit and edit manually |
| Cons | Manual curation burden; no semantic search; contradictions and stale entries accumulate silently; grows unwieldy over time |
| Best for | Small setups, early stages, or when you want full manual control |
This is solid as a starting point. But it does not scale once you have more than a few hundred lines of context.
Option 3: Vector / Semantic Search
Store memory as embeddings and retrieve relevant chunks by semantic similarity at query time. This is the approach used by systems like MemGPT and LangChain's memory modules.
| Dimension | Details |
|---|---|
| How it works | Memories chunked and embedded; relevant chunks retrieved at inference time |
| Pros | Scales well; retrieves relevant context without loading everything; handles large corpora |
| Cons | Requires embedding infrastructure; harder to audit; retrieval quality depends on chunking and embedding quality; not human-readable |
| Best for | Large-scale personal knowledge bases, enterprise agents, systems with thousands of memories |
Source: MemGPT: Towards LLMs as Operating Systems (2023)
Option 4: Structured Knowledge Graph
Memory stored as entities and relationships — a graph where nodes are people, projects, events, and concepts, and edges are the relationships between them.
| Dimension | Details |
|---|---|
| How it works | Agent writes and reads from a structured graph (e.g. via tools or a knowledge base API) |
| Pros | Highly structured; enables rich querying; great for tracking relationships between entities |
| Cons | High setup cost; requires consistent schema; hard to maintain without dedicated tooling |
| Best for | Complex multi-entity domains where relationships matter (e.g. CRM, research systems) |
Source: Microsoft Research: GraphRAG (2024)
Option 5: Wiki / Compiled Knowledge Layer
A curated set of structured wiki pages — one per entity, topic, or domain — that are compiled from source files and searched together. This is the approach OpenClaw's memory wiki feature implements.
| Dimension | Details |
|---|---|
| How it works | Source markdown files compiled into structured wiki pages with frontmatter; searched via memory_search(corpus="wiki") |
| Pros | Human-readable and auditable; structured with frontmatter; provenance-aware; supports corpus=all for combined search |
| Cons | Requires initial setup and periodic maintenance; not as automatic as vector search |
| Best for | Personal knowledge systems where you want both human control and machine-readable structure |
This is what I built in Part 7, and I will explain why in a moment.
My Setup Before
Here is exactly what I had before in Part 4, and what was missing.
What Was Working
| Concept | My actual setup |
|---|---|
| Raw daily logs | memory/YYYY-MM-DD.md files — one per day, raw notes from each session |
| Long-term memory | MEMORY.md — manually curated over time; contains system references, past decisions, standing rules |
| Schema and instructions | AGENTS.md, SOUL.md, TOOLS.md — loaded at session start, defines how the agent behaves |
| User context | USER.md — Victoria's preferences, timezone, channels, YouTube handles |
These files did real work. The agent knew my timezone, my Todoist token path, my Telegram topic IDs, my YouTube channels. That is not nothing.
What Was Missing
But there were real gaps that became more obvious as the system grew.
No semantic search. The memory_search tool exists and supports a corpus="wiki" parameter. But I had nothing registered under that corpus. Searches hit MEMORY.md only, and only with limited semantic matching.
No entity pages. There was no structured page for ragTech as a concept — its hosts, tone rules, Buffer channel IDs. No page for WomenDevs Singapore. No structured summary of my blog setup. These things existed scattered across MEMORY.md and TOOLS.md, but not as coherent searchable units.
No auto-maintenance. MEMORY.md accumulated entries over time. There was no process to check for contradictions, flag stale info, or identify open questions the agent had logged but never resolved.
No provenance. If the agent found a fact in MEMORY.md, it had no way to know when that was written, how confident the source was, or whether a newer entry elsewhere contradicted it.
Manual wiki curator. All of this depended on me. I updated MEMORY.md when I remembered to. I resolved contradictions when I spotted them. The system could not maintain itself.
This was fine early on. It was not fine at the scale I was operating.
What I Built: The Memory Wiki
OpenClaw ships with a memory wiki feature that compiles source files into a structured wiki vault — readable by humans, indexed for the agent, and provenance-aware.
Here is what I set up.
The Source Layer
Six files form the foundation of the wiki:
MEMORY.md — system references, standing rules, past decisions
USER.md — Victoria's profile, preferences, timezone, social handles
TOOLS.md — tool setup notes, API paths, common commands
memory/orgs.md — full context on ragTech and WomenDevs Singapore
memory/blog-context.md — blog structure, mandatory intro/outro, Hashnode integration
memory/LESSONS_LEARNED.md — documented mistakes and corrections, maintained by the self-improvement skill
These are the source of truth. The wiki compiles from them; it does not replace them.
The Entity Pages
From those sources, I generated four structured entity pages.
entities/victoria.md — my profile page. Timezone, social handles, channel IDs, content preferences, style rules for scripts and blog posts. Anything the agent needs to act on my behalf in a context-aware way.
entities/ragtech.md — the podcast. Hosts (Natasha Ann Lum, Saloni Kaur, Victoria Lo), tone guidelines, Buffer channel IDs for LinkedIn and TikTok and Instagram, LinkedIn post rules, script format for Instagram reels.
entities/womendevs-sg.md — WomenDevs Singapore. Mission, tone (inclusive, celebratory, community-first), LinkedIn handle, content types, what the organization should and should not sound like.
entities/blog.md — the blog. Mandatory intro sentence, mandatory ending format, article flow structure, style rules, Hashnode integration details.
Each entity page has frontmatter that includes a unique ID, aliases, privacy tier, what the entity is best used for, and a lastRefreshedAt timestamp. That timestamp is what enables the stale-pages report.
The Report Dashboards
Five auto-generated reports live in reports/ and get refreshed when the wiki is rebuilt.
stale-pages.md — pages that have not been refreshed in over 30 days
contradictions.md — entries in different pages that contradict each other (e.g. a channel ID appearing with different values in two places)
open-questions.md — questions the agent logged but never resolved
claim-health.md — low-confidence or unverified claims that should be reviewed
low-confidence.md — entries marked uncertain or inferred rather than confirmed
These reports do not fix problems automatically. They surface them so I can fix them deliberately. That matters more than you might think.
Search Now Works
Before this, memory_search(corpus="wiki") hit nothing. There was no registered wiki corpus.
Now it works. When the agent runs memory_search(corpus="wiki"), it searches across all compiled wiki pages — the entity pages, the source summaries, and the reports. When it runs memory_search(corpus="all"), it searches both MEMORY.md and the wiki in a single pass.
The results include provenance: which page the fact came from, what its confidence level is, and when it was last refreshed. The agent can reason about the reliability of what it finds, not just the content.
Why This Architecture, Specifically
I chose the wiki approach over vector search or a knowledge graph for reasons that came down to my actual constraints and values.
I want to read my own memory. Vector stores are opaque. I cannot open a file and see what the agent knows. With the wiki, I can open entities/ragtech.md and read exactly what the agent knows about ragTech. I can edit it. I can catch a mistake and fix it in two minutes.
I want version control. Every wiki page is a markdown file. The entire wiki lives in ~/.openclaw/wiki/main/. I can git diff it. I can see what changed and when. I can roll back a bad update. You cannot do that with a vector database without significant extra infrastructure.
I want provenance. The frontmatter approach lets each page declare its source, its confidence level, its last refresh date, and what it is best and worst used for. When the agent retrieves a fact, it can see whether that fact is fresh or stale, confirmed or inferred.
I want the agent to know its own limitations. The bestUsedFor and notEnoughFor fields in entity frontmatter are instructions to the agent about when to trust this page and when to ask me instead. That is not something you get from a flat file or an embedding.
The Compound Effect: Why This Matters Long Term
Here is the real argument for why this is worth building.
Every session the agent runs, it potentially learns something. A new preference I mention. A correction I make. A decision I document. In a flat-file system, those learnings either get captured in MEMORY.md (if I remember to write them down) or they disappear.
In a wiki system with source files and structured entity pages, the knowledge compounds. Each refresh picks up changes from source files. Contradictions get surfaced before they cause errors. Stale information gets flagged before it misleads the agent. Entity pages stay coherent because they have a defined schema.
Over six months, the difference is enormous. A flat-file agent has a MEMORY.md that is increasingly hard to parse and increasingly likely to contain outdated or contradictory information. A wiki agent has a searchable, structured knowledge base that has been incrementally cleaned and updated. The second agent acts more accurately, makes fewer wrong assumptions, and needs less manual correction.
Knowledge compounds. Entropy is the enemy. The wiki is how you fight entropy.
How to Maintain It (And Keep It Secure)
Setting this up is the start, not the end. Here is how I plan to keep it healthy.
Maintenance Habits
Refresh entity pages after major changes. If I change my blog format, update entities/blog.md. If ragTech adds a new social channel, update entities/ragtech.md. Entity pages are only useful if they stay current.
Review reports in heartbeats. The stale-pages and contradictions reports are most useful if someone actually looks at them. I am adding a periodic heartbeat check: if a page has not been refreshed in 45+ days, surface it. If a contradiction report has new entries, flag it.
Write to source files first. The wiki compiles from source files. The discipline is: when something changes, update the source file (USER.md, TOOLS.md, orgs.md, etc.), then rebuild the wiki. Do not edit entity pages directly and hope the source catches up.
Use LESSONS_LEARNED.md as a live document. The self-improvement skill writes to this file when errors or corrections happen. When the wiki is rebuilt, those lessons get compiled in. This means the agent's documented mistakes become searchable knowledge rather than buried session history.
Security Notes
Private data stays local. The wiki lives at ~/.openclaw/wiki/main/ — it is a local file system path, not a cloud service. Nothing in the wiki is sent anywhere unless the agent is specifically instructed to include wiki content in an outbound message.
Privacy tiers on entity pages. The victoria.md entity page is tagged privacyTier: local-private. This tells the agent not to include it in summaries or responses in group or public sessions. The agent loads MEMORY.md only in direct sessions with me — the same logic applies to the wiki.
Do not put credentials in entity pages. API tokens and auth details belong in .env files and TOOLS.md, not in the wiki. The wiki is for knowledge — who, what, how, why. Credentials are operational secrets and should be treated accordingly.
Audit the reports periodically. The contradictions.md report is your canary. If two pages say different things about the same fact, one of them is wrong. Finding and fixing that before the agent acts on it is much better than debugging a mistake after the fact.
Version control the wiki. If you are comfortable with git, version-controlling ~/.openclaw/wiki/ is worth doing. It gives you a recovery path if a bad rebuild overwrites something important.
What Is Next
This is now a working, searchable, compound-knowledge system. But there are things I still want to do.
The immediate next experiments:
Scheduled wiki rebuilds — auto-refresh entity pages weekly so the stale-pages report stays meaningful without manual triggers
Heartbeat-driven contradiction checks — surface contradictions.md entries proactively, not just when I remember to look
Inbox-driven wiki updates — when a new collab email arrives or a new task is completed, use that as a signal to update the relevant entity page
Expanding entity coverage — a wiki/projects.md for active technical projects, a wiki/contacts.md for people I collaborate with frequently
The longer vision is an agent that genuinely accumulates expertise over time. Not because it has a bigger context window, but because it maintains structured, auditable knowledge about the domain it operates in. That is what this wiki layer is building toward.
Conclusion
Memory is not a nice-to-have for an agentic system. It is what separates a tool that reacts from one that understands.
What I built in this part: entity pages, source compilation, provenance-aware search, maintenance reports. This is not the most technically sophisticated memory system possible. But it is auditable, human-readable, version-controllable, and designed to improve over time rather than degrade.
The wiki is live. corpus=all searches both MEMORY.md and the wiki in one pass. Knowledge from six source files and four entity pages is now structured, searchable, and accessible in every session.
Thanks for reading! I am curious to know your own personal thoughts and experiences on this topic! Feel free to connect, send me an email (my inbox is always open) or let me know in the comments! Cheers!
