How to Build an AI Brain

A practical guide to giving your AI agent persistent memory, from workspace files to graph databases. Four layers, starting from trivial to advanced.

How to Build an AI Brain: Persistent Memory for OpenClaw & Claude Code

A practical guide to giving your AI agent institutional memory, from zero to four-layer recall.


Why This Matters

Nate B Jones recently laid out the thesis that the next enterprise platform war has nothing to do with models, it is about context. The company that solves trillion-token organizational memory with reliable retrieval wins everything. The model with access to all the filing cabinets at once will always outperform the smarter model that starts from scratch every time.

“When a senior engineer quits, the filing cabinets are still full. What’s gone is the person who knew which cabinets to open and how to connect the contents together.”

His full analysis: OpenAI Leaked GPT-5.4. It’s a Distraction. (The AI Lock-In No One Is Talking About), Nate B Jones, AI News & Strategy Daily, March 5, 2026.

Here’s the thing, you don’t need to wait for OpenAI’s stateful runtime or Anthropic’s productized context layer. You can build a working version of this right now, at personal or small-team scale, using OpenClaw or Claude Code’s native CLAUDE.md system. It will not be trillion-token enterprise scale, but it will fundamentally change how your AI agent operates. Instead of an amnesiac that wakes up fresh every session, you get something that actually knows your world.

This guide documents how we built exactly that for a small operations agent running on a Raspberry Pi. The same architecture works for any OpenClaw agent or Claude Code project.


The Core Problem

Every AI session starts from zero. Your agent doesn’t know:

  • What you worked on yesterday
  • What decisions were made and why
  • What broke last time and how it was fixed
  • Your preferences, your infrastructure, your people
  • The context that makes its answers actually useful

This is Nate’s “synthesis layer” problem at individual scale. The information exists, in chat logs, in your head, in scattered files. The agent can’t access any of it without you manually re-explaining everything. Every session is a new hire’s first day.

The Solution: Four Memory Layers

We solve this with a layered architecture. Each layer has different strengths, and they complement each other. You don’t need all four, Layer 1 alone is transformative. Each additional layer adds capability.

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚          Layer 4: Graph Memory (MEM0)            β”‚
β”‚   Entity relationships Β· Cross-agent recall      β”‚
β”‚   "MuddyWater β†’ uses β†’ CHAR β†’ via β†’ Telegram"   β”‚
β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€
β”‚          Layer 3: Structured Knowledge DB        β”‚
β”‚   SQLite tables Β· SQL-queryable facts            β”‚
β”‚   Study materials Β· Network inventory Β· Tasks    β”‚
β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€
β”‚          Layer 2: Vector/Semantic Search          β”‚
β”‚   Embeddings Β· Fuzzy recall Β· Session transcriptsβ”‚
β”‚   "Find anything related to that DNS issue"      β”‚
β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€
β”‚          Layer 1: Workspace Files (Foundation)   β”‚
β”‚   MEMORY.md Β· Daily logs Β· Identity files        β”‚
β”‚   Always loaded Β· Always available Β· Ground truthβ”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

Layer 1: Workspace Files (Start Here)

Works with: OpenClaw βœ… | Claude Code βœ… Difficulty: Trivial Impact: Massive

This is the foundation. Both OpenClaw and Claude Code automatically load markdown files from your workspace into every session context. Your agent reads these before responding to anything.

For OpenClaw

OpenClaw loads all .md files from your workspace directory (~/.openclaw/workspace/) as “Project Context” at the start of every session.

Create these files:

~/.openclaw/workspace/
β”œβ”€β”€ MEMORY.md          # Long-term curated memory (the big one)
β”œβ”€β”€ AGENTS.md          # Operational guidelines, security, role
β”œβ”€β”€ SOUL.md            # Personality, communication style
β”œβ”€β”€ IDENTITY.md        # Who the agent is
β”œβ”€β”€ USER.md            # Who you are, preferences, context
β”œβ”€β”€ TOOLS.md           # Local tool docs, SSH configs, gotchas
└── memory/
    β”œβ”€β”€ 2026-03-01.md  # Daily operational logs
    β”œβ”€β”€ 2026-03-02.md
    └── ...

For Claude Code

Claude Code loads CLAUDE.md from your project root. Same concept, single file.

your-project/
β”œβ”€β”€ CLAUDE.md          # Everything Claude needs to know
β”œβ”€β”€ memory/
β”‚   └── YYYY-MM-DD.md  # Daily logs (reference from CLAUDE.md)
└── ...

What Goes in MEMORY.md / CLAUDE.md

This is your agent’s long-term brain. Think of it as the briefing document for a new team member who needs to be productive immediately:

# MEMORY.md

## Infrastructure
- Host: patchwork (Pi 5, 10.0.50.12)
- NAS: 10.0.50.1 (SMB mount at /mnt/shared/)
- Docker containers: [list them]

## Standing Orders
1. Monitor systems, don't interfere unless needed
2. If primary agent goes down, step up
3. Keep operator informed of anomalies

## Lessons Learned
- Speed key in TTS config crashed gateway 659 times. DON'T.
- Zsh glob-expands ? in URLs, always quote curl URLs
- Local Ollama too weak on Pi, offload to GPU box

## File Locations
- Docs: /mnt/shared/agent-bravo/docs/
- Audio: /mnt/shared/agent-bravo/audio/
- Backups: /mnt/external/BKUP/

## Current Projects
- Network segmentation lab (in progress)
- OSINT archive: 51GB on external drive

Daily Logs

Create a new file each day the agent is active:

# 2026-03-05

## Git Backup Setup
- Initialized workspace git repo, pushed to Gitea
- Created RECOVERY.md (placed at ~/, Gitea, external drive)
- Automated nightly commit+push at 23:00

## Firewall Audit
- Reviewed UFW rules on gateway box
- Closed two stale forwarding rules from old lab
- Verified NAS only reachable from management VLAN

The Key Discipline

Update these files during sessions. Non-negotiable. If something important happened, a fix, a decision, a new tool installed, a lesson learned, write it down before the session ends. Your future agent self depends on it.

This is exactly Nate’s point about memory that doesn’t rot: “The decision that was correct 6 months ago may have been superseded. Memory that preserves context without updating it is worse than no memory at all.”

Curate actively. Remove outdated info. Mark what’s current vs. historical.


Works with: OpenClaw βœ… (built-in) | Claude Code ⚠️ (needs external tooling) Difficulty: Easy (OpenClaw) / Moderate (Claude Code) Impact: High, enables fuzzy recall across all text

Layer 1 is loaded into every session, but it’s limited by context window. You can’t put 50 daily log files into system context. Vector search solves this, it indexes all your markdown files and lets the agent semantically search across them.

For OpenClaw

OpenClaw has this built in. Configure a Gemini API key and it automatically:

  • Indexes all workspace .md files
  • Indexes session transcripts
  • Provides memory_search and memory_get tools to the agent
  • Uses hybrid BM25 + vector search with MMR
# Set the API key in your gateway service environment
# ~/.config/systemd/user/openclaw-gateway.service
# Add to [Service] section:
Environment="GEMINI_API_KEY=your-key-here"

# Restart gateway
systemctl --user restart openclaw-gateway

The agent can then do:

memory_search("that DNS issue from last week")
β†’ Returns relevant snippets with file paths and line numbers

For Claude Code

Claude Code doesn’t have built-in vector search, but you can approximate it:

Option A: Large CLAUDE.md Keep a well-curated CLAUDE.md under ~4000 lines. Claude Code loads the whole thing. For small-to-medium projects, this is sufficient.

Option B: CLI search tool Give Claude Code access to a search script it can call:

#!/bin/bash
# search-memory.sh
grep -rn -i "$1" memory/ CLAUDE.md --include="*.md" | head -20

Claude Code can shell out to this via its bash tool.

Option C: External vector DB Set up a lightweight embedding search (e.g., using Python + sentence-transformers + FAISS) and expose it as a CLI tool. More work, but enables true semantic search.


Layer 3: Structured Knowledge DB

Works with: OpenClaw βœ… | Claude Code βœ… Difficulty: Moderate Impact: Medium, great for queryable facts

Some knowledge is better stored as structured data than prose. A SQLite database that the agent can query gives you SQL-powered recall.

sqlite3 knowledge.db << 'SQL'
CREATE TABLE network_inventory (
    host TEXT, ip TEXT, role TEXT, os TEXT, notes TEXT
);
CREATE TABLE tasks (
    id INTEGER PRIMARY KEY, description TEXT,
    status TEXT, created TEXT, completed TEXT
);
CREATE TABLE lessons_learned (
    id INTEGER PRIMARY KEY, topic TEXT,
    lesson TEXT, date TEXT, severity TEXT
);
SQL

Both OpenClaw and Claude Code can execute sqlite3 commands via their shell tools. The agent can query its own knowledge base:

SELECT * FROM lessons_learned WHERE topic LIKE '%TTS%';
-- Returns: "Don't add speed key to openclaw.json, crashes gateway"

Layer 4: Graph Memory (MEM0)

Works with: OpenClaw βœ… | Claude Code βœ… (via API) Difficulty: Advanced Impact: High, enables relational knowledge and cross-agent memory

This is the closest thing to what Nate describes as the enterprise synthesis layer. MEM0 stores memories as both vector embeddings AND a knowledge graph. Beyond finding similar text, it understands relationships between entities.

operator --manages--> homelab
agent-bravo --runs_on--> patchwork
MuddyWater --sponsored_by--> Iran MOIS
MuddyWater --uses--> CHAR malware
CHAR --communicates_via--> Telegram C2

Self-Hosted MEM0 Setup

# docker-compose.yaml
version: '3.8'
services:
  mem0:
    image: mem0ai/mem0:latest
    ports:
      - "8880:8080"
    depends_on:
      - postgres
      - neo4j

  postgres:
    image: pgvector/pgvector:pg16
    ports:
      - "8432:5432"
    environment:
      POSTGRES_PASSWORD: postgres
    volumes:
      - pgdata:/var/lib/postgresql/data

  neo4j:
    image: neo4j:5
    ports:
      - "7687:7687"
      - "8474:7474"
    environment:
      NEO4J_AUTH: neo4j/mem0graph
    volumes:
      - neo4jdata:/data

volumes:
  pgdata:
  neo4jdata:
docker-compose up -d
sleep 30

# Configure MEM0 to use your LLM
curl -X POST http://localhost:8880/configure \
  -H "Content-Type: application/json" \
  -d '{
    "llm": {
      "provider": "ollama",
      "config": {"model": "qwen3:8b", "ollama_base_url": "http://your-gpu-host:11434"}
    },
    "embedder": {
      "provider": "ollama",
      "config": {"model": "nomic-embed-text", "ollama_base_url": "http://your-gpu-host:11434"}
    }
  }'

Adding and Searching Memories

# Add a memory
curl -X POST http://localhost:8880/memories \
  -H "Content-Type: application/json" \
  -d '{"messages": [{"role": "user", "content": "Agent Bravo runs on patchwork Pi 5 at 10.0.50.12"}], "user_id": "bravo"}'

# Search
curl -X POST http://localhost:8880/search \
  -H "Content-Type: application/json" \
  -d '{"query": "what host does bravo run on", "user_id": "bravo"}'

Cross-Agent Memory

Multiple agents sharing the same MEM0 instance with different user_id scopes. Each agent writes to its own scope but can read from others.

# Agent Bravo writes
{"user_id": "bravo", "messages": [{"role": "user", "content": "NAS backup paused"}]}

# Agent Alpha searches across both
for uid in ["alpha", "bravo"]:
    results = search(query="backup status", user_id=uid)

Primitive shared organizational context, exactly what Nate describes, at agent-team scale.

Automated Consolidation

Set up a cron job to feed daily logs into MEM0:

# Every 15 minutes, read today's memory file and store new facts
*/15 * * * * ~/.local/bin/memory-consolidate >> /tmp/consolidate.log 2>&1

Version Control: The Rollback Safety Net

Your agent’s brain should be in git. When files are the memory, git gives you:

  • History: when a memory was added or changed
  • Rollback: revert a bad edit that confused the agent
  • Backup: push to Gitea/GitHub for offsite copies
  • Diff: track what changed between sessions
cd ~/.openclaw/workspace  # or your Claude Code project
git init
git remote add origin https://your-gitea/your-repo.git

# .gitignore
echo "*.db\n*.png\n*.mp3\nSECURITY.md\nsessions/" > .gitignore

# Nightly auto-backup (add to cron)
0 23 * * * cd ~/.openclaw/workspace && git add -A && \
  git commit -m "Auto-backup: $(date '+%Y-%m-%d %H:%M')" && \
  git push origin master

Claude Code Specific Notes

Claude Code’s CLAUDE.md is the equivalent of OpenClaw’s workspace files. The key differences:

Feature OpenClaw Claude Code
Auto-loaded context All workspace .md files CLAUDE.md only
Vector search Built-in (Gemini) DIY
Session transcripts Stored and searchable Not persisted by default
Memory tools memory_search, memory_get Shell access only
Multi-agent Built-in sessions/messaging Not built-in

For Claude Code users, the practical approach is:

  1. Start with a well-structured CLAUDE.md, this alone is 80% of the value
  2. Add a memory/ directory with daily logs, reference from CLAUDE.md
  3. Give Claude Code a search script it can call for fuzzy lookup
  4. Use git for version control and rollback
  5. If you want MEM0, set it up as a Docker service and give Claude Code a CLI wrapper to query it

The same memory architecture works for both platforms. The files are identical, only the loading mechanism differs.


What This Gets You

With all four layers running, your agent can:

  • Wake up knowing your world, infrastructure, people, preferences, history
  • Recall past decisions and why they were made, the reasoning, not just the outcome
  • Learn from mistakes, lessons learned persist across sessions
  • Search fuzzy context, “that thing we fixed last Tuesday” actually works
  • Share knowledge across agents, one agent’s discovery benefits all
  • Roll back bad memory, git revert if something goes wrong

Your agent becomes a team member with institutional memory. It knows which filing cabinets to open.


The Honest Limitation

What we’ve built is primitive compared to the vision in the video. We’re at maybe thousands of documents, not trillions of tokens. Our retrieval is good but not enterprise-grade. The knowledge graph has hundreds of nodes, not millions.

But here’s the thing Nate also said: “Don’t wait. You can’t bet on that. Build now.”

A few thousand well-curated memories with reliable retrieval beats a trillion tokens of unprocessed organizational noise. The agent that knows your 50 most important facts cold is more useful than one that has vague access to everything.

Start with Layer 1. Add layers as you need them. The compound improvement is real, we went from an agent that forgot everything between sessions to one that wakes up knowing the infrastructure, the people, the projects, the mistakes, and the standing orders. Every session builds on the last.

That’s the flywheel. It’s already spinning.


References

Jones, N.B. (2026) ‘OpenAI Leaked GPT-5.4. It’s a Distraction. (The AI Lock-In No One Is Talking About)’, AI News & Strategy Daily, 5 March. Available at: youtube.com

Jones, N.B. (2026) ‘Your Engineers Are Building Your Moat’, Nate’s Newsletter. Available at: natesnewsletter.substack.com

OpenClaw (2026) Documentation. Available at: docs.openclaw.ai

Anthropic (2026) Claude Code Documentation. Available at: docs.anthropic.com

MEM0 (2026) Self-hosted memory layer. Available at: github.com/mem0ai/mem0


“The filing cabinets are still full. What’s gone is the person who knew which cabinets to open.” Nate B Jones

We built the person who never leaves. FTRCRP, 2026