Memory

• Amnesia-Free Agents: GBrain and the LLM Wiki Idea

  Every agent I work with has amnesia.

  Open a new terminal session, spin up a subagent, start a fresh chat, and the thing forgets everything. Your project guidelines, your coding style, your database schemas, the meeting where you decided why the schema looks like that. Gone. So you do one of two things: stuff a few thousand tokens into a bloated system prompt, or hand-maintain fragile context files like CLAUDE.md. I’ve done both. Neither feels good.

  So when Y Combinator CEO Garry Tan open-sourced GBrain on April 5, 2026, a markdown-first memory layer, I wanted to understand what it does and whether it’s worth the setup.

  What GBrain actually is

  GBrain is a Postgres-native knowledge brain that acts as a persistent retrieval layer for your coding agents. The interesting part isn’t that it stores stuff, it’s how opinionated it is about the shape of that storage.

  Three ideas do the heavy lifting:

  • Compiled truth vs. an append-only timeline. Raw daily logs, Slack messages, and emails go in one bucket. The curated “current facts” (contacts, active projects, decisions) live as clean Markdown in another. One is history, the other is truth.
  • A self-wiring knowledge graph. It parses your plain Markdown and pulls out relationships (works_at, invested_in, founded) using local grammars. No LLM API calls to build the map.
  • The Dream Cycle. An overnight cron job that crawls your daily logs, reconciles contradictions, checks citations, and rebuilds the search index while you sleep.

  That last one worth a callout: Memory that maintains itself.

  The category error everyone makes

  People keep comparing GBrain to runtime agents like OpenClaw or Hermes, and that comparison doesn’t hold up. They’re different layers entirely.

  GBrain isn’t an execution engine. It’s closer to a self-writing wiki.

    ┌────────────────────────────────────────────────┐
    │                AGENT RUNTIMES                    │
    │       (OpenClaw, Hermes, Claude Code)            │
    │   runs code, spawns subagents, hits the shell    │
    └─────────────────────────┬────────────────────────┘
                              │  reads & writes via MCP
                              ▼
    ┌────────────────────────────────────────────────┐
    │                  THE LLM WIKI                    │
    │               (GBrain, OpenWiki)                 │
    │    compiles raw history into clean markdown      │
    └────────────────────────────────────────────────┘
  

  The runtime is the hands and eyes. It sandboxes code, runs terminal commands, touches the file system. The wiki is the long-term memory. You wire them together over the Model Context Protocol (MCP), and when the agent needs context, it doesn’t parse your raw email history. It queries the wiki and gets back synthesized, cited facts.

  GBrain isn’t the only thing playing this role. OpenWiki, from the LangChain folks, uses the same trick to compile big source repos into navigable markdown. Same pattern, different input.

  The payoff: your agent stays lightweight and task-focused, and your knowledge lives in a clean, git-versioned wiki instead of leaking into a system prompt.

  What people actually run into

  The concept is great. The reality has some sharp edges, and the community forums are honest about them.

  It needs babysitting. GBrain moves fast, which means frequent schema updates and migrations. You’ll find yourself running things like gbrain doctor --remediate to fix database drift. It is not set-it-and-forget-it.

  Tool sprawl adds up. To feed the Dream Cycle good data, people bolt on voice transcribers, contact enrichers, email scrapers. Most of those are paid SaaS. String enough together and you’ve built yourself a subscription problem.

  Setup is a project. A Dockerized Postgres with pgvector, system keyring wrangling (macOS Keychain or D-Bus), cron schedulers. Budget anywhere from 30 minutes to a lost afternoon.

  Should you bother?

  If you’re juggling complex work across a bunch of codebases, and you want an agent that knows your past architecture decisions and updates its own docs overnight, the GBrain + OpenClaw setup earns its keep. That’s a real moat.

  If you just want a lightweight assistant that remembers a few things, you’re better off with plain MEMORY.md files or a hosted API like Mem0 until the local graph-RAG tooling settles down. I’m somewhere in the middle right now, so I’ll watching it to see where it goes.

  Amnesia is the default. It doesn’t have to be.

  Sources

  • GBrain repository
  • OpenClaw agent framework
  • Hermes Agent (Nous Research)
  • /r/openclaw community threads
  • Hacker News

  I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].

  Jul 13, 2026 AI Developer-tools Agents LLM Memory

  Enjoyed this?

• Two Kinds of Memory for Your CLI Agent

  So you set up a memory layer for your local CLI agent. Now what? How do you actually get that memory in front of the agent so it does something useful?

  I’m going to walk through what I did with mem0, but the shape of this applies to pretty much any memory layer. The first thing worth understanding is that CLI agents work with memory in two very different ways, and the difference matters.

  The first way is text that’s always loaded. It gets injected into every session’s context automatically. No action needed on the agent’s part, it’s just there. This is your guaranteed data, the stuff that shows up at the start of every conversation.

  The second way is semantic memory. For me that’s mem0 and the tooling I’ve built around it. This layer is accessed through an MCP server that exposes commands like recall and remember. It’s poll-based. The agent has to decide to call recall, because nothing gets auto-injected. The agent needs to be smart enough to say “I’m not sure about this, let me go look it up.”

  Those are the two flavors. Let me break them down.

  Layer 1A: The Shared Instructions File

  For most CLI agents, this is a single markdown file that the harness auto-loads into every session. Claude Code reads CLAUDE.md. Gemini and Antigravity read GEMINI.md. And AGENTS.md has become the cross-tool convention, read by OpenCode, Antigravity, and Cursor alike. Same idea everywhere, just a different filename.

  The one rule here: keep it minimal. Every line in this file is context you’re paying for on every single session. So don’t dump your whole knowledge base into it. The durable conventions, the project-specific facts, the things you only occasionally need? Those belong in your semantic layer, not here. This file is for the handful of rules that need to be loaded 100% of the time.

  Layer 1B: Auto-Memory

  Claude Code shipped a feature called auto-memory. It lives in ~/.claude/projects/, inside a subfolder that’s basically a slug of your project’s path on disk. In there you get a memory folder with a MEMORY.md file alongside the individual memory files.

  MEMORY.md works like an index. It holds short pointers to the durable memories stored next to it, and the whole thing gets loaded every session. It’s still part of layer 1, the always-loaded kind.

  Worth noting: this is a Claude Code thing. OpenCode and Antigravity don’t load or even know about these files. There’s no equivalent. Antigravity does have its own separate memory store that it syncs on its own, but it’s a different mechanism entirely, not a reader of Claude’s auto-memory.

  Layer 2: The Semantic Layer

  This is where it gets fun. I built a small MCP server in Go, a local binary that forwards requests to another server on my network. That server talks to two databases: Qdrant for the vectors, and Neo4j for the graph. The three functions I lean on most are recall, remember, and add_relation.

  If MCP is new to you, the short version: it’s an open standard that lets your agent connect to external tools and data over a common protocol. Instead of N bespoke integrations, you run one MCP server per capability and the host discovers it. People call it “a USB-C port for AI,” which is annoying and also pretty accurate.

  Wiring it up is just config. For Claude Code, it goes in ~/.claude.json under the top-level mcpServers.memory block. For OpenCode, it’s ~/.config/opencode/opencode.json under mcp.memory, with type: local and a command that runs the binary.

  The Part People Forget

  Here’s the step that ties it all together. Setting up the MCP server doesn’t do anything on its own. Remember, the semantic layer is poll-based. The agent won’t call recall unless it knows it should.

  So you go back to layer 1, your always-loaded instructions, and you add a few lines telling the agent how and when to use the MCP server. Something like “before answering questions about this project, call recall with a relevant query” and “when the user tells you something worth keeping, call remember.” That instruction is small, it’s cheap, and it’s what turns a dormant memory store into a memory layer the agent actually reaches for.

  That’s the whole architecture. Always-loaded text that’s guaranteed but expensive, and a semantic store that’s huge but only as good as the agent’s instinct to go check it. Get both layers talking and your agent stops forgetting who you are every morning.

  Sources

  • mem0 — GitHub — the universal memory layer for AI agents that the post describes wiring up; 59.6k stars, Apache 2.0.
  • Model Context Protocol — Wikipedia — MCP as an open standard introduced by Anthropic (Nov 2024) for connecting AI systems to external tools and data sources.
  • Emma Roth, “Anthropic launches tool to connect AI systems directly to datasets” (The Verge, Nov 25, 2024) — news coverage of the MCP launch; confirms the “USB-C port for AI” framing and the standard-protocol pitch.
  • Jonathan Kemper, “Claude Code now remembers your fixes, your preferences, and your project quirks on its own” (The Decoder, Feb 27, 2026) — news coverage of the auto-memory feature; confirms the MEMORY.md per-project file and the ~/.claude/projects/ directory structure.
  • How Claude remembers your project — Claude Code Docs — official documentation for CLAUDE.md files and the auto-memory system.

  I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].

  Jun 30, 2026 AI Tools Agents Mcp Memory

  Enjoyed this?