Everyone who's set up a nightly review for their agent has had the same thought: let it summarize on its own overnight, wake up smarter tomorrow. I did too. Hermes and OpenClaw are two popular agent runtimes, the layer that actually wakes your agent up, runs its tools, and sends results back. Hermes can fire on a cron schedule. OpenClaw has Dreaming, which consolidates short-term signals into long-term memory candidates. But after running this for a while, I found that if each one only stores things inside its own runtime, what you end up with is two agents keeping separate diaries.

A system that actually works keeps three things apart:

This is why I ended up putting gbrain above both Hermes and OpenClaw. Hermes and OpenClaw are peer runtimes. They run the loop, call tools, fire on schedule, and send results back to me. gbrain is different: an open-source structured knowledge layer

It can run its own ingestion, dream cycle, even a full agent on top. But in this setup I don't use it as a runtime. I use it for one job: deciding how today's events should surface tomorrow. This article has nothing to do with switching on some Dreaming feature. It's about how to use gbrain to build one shared AI second brain on top of your runtime, whether you run Hermes or OpenClaw.

1. Separate the three layers first I now split the whole system into three layers:

These three can't be mixed. Hermes / OpenClaw: who does the work Hermes is good for personal agent loops that wake on a fixed schedule: a morning summary, a nightly audit, a periodic check, results pushed back to Telegram, Slack, or the CLI. A normal Hermes session has its own persistent memory: MEMORY.md / USER.md injected at session start, plus a session_search tool to pull up past conversations on demand. Cron is a different story. A Hermes cron job is fired by the gateway daemon, and every run starts a fresh agent session that doesn't inherit your current chat context. The current implementation also skips memory providers during cron (skip_memory=True by default). So a 1am job has to carry its own context: a self-contained prompt, context_from, workdir or context files, or a direct read from gbrain. In my own usage, OpenClaw fits the workspace / channel routing / multi-agent / Dreaming layer better. Its memory is file-based too: MEMORY.md is the compact curated layer, daily notes are the working layer. OpenClaw also has Dreaming, a background memory consolidation mechanism, opt-in and off by default. Internally it has three phases (Light / REM / Deep), and only Deep writes durable candidates into MEMORY.md. Useful, but still consolidation inside one runtime. So Hermes wakes up and runs, OpenClaw wakes up and runs, but on their own they don't add up to one shared brain. They're the hands that do the work. The brain has to sit one level above them. 2. Why you need gbrain as a third layer At first I thought nightly review was enough. It wasn't. The agent did summarize. But the next session doesn't always find that summary when it needs it. One day, a well-known developer reacted badly to one of our AI-flavored replies. That night, the agent had already recorded:

If that line stays in one runtime's cron output or daily memory, the next time a different runtime picks up the task, or you move to another machine, the lesson is gone. Even if you sync both MEMORY.md files by hand, the long-term memory slowly drifts apart.

That's why I added gbrain on top. First, one thing to be clear about: OpenClaw and Hermes already have memory of their own. OpenClaw has daily notes, MEMORY.md, memory_search / memory_get, Dreaming, and Active Memory (in eligible interactive sessions, a blocking recall sub-agent runs before the main reply and pulls relevant memories in). Hermes has MEMORY.md / USER.md and session_search. So if you only run one of them, its own memory is enough to start. You don't need gbrain yet. gbrain solves the step after that: when you run Hermes and OpenClaw at the same time, or you'll switch runtimes later, the state of a long-lived object shouldn't live in two copies that slowly drift apart. It's an open-source structured knowledge layer that sits outside any single runtime: Hermes can read it. OpenClaw can read it. A nightly job can write it. An audit job can revise it. The next agent that wakes up picks up from the same brain page. Multiple runtimes sharing one brain. That's what starts to feel like a second brain. 3. A second brain is about one current state When I look at a piece of information now, I don't start with "should I save this." I start with "which layer should it go into." I sort information into five fates:

Examples:

The one that matters most is the third layer. A gbrain page answers what this object is right now. It tracks the current state of a person, a company, a project, a concept, a writing asset. For example:

This kind of information shouldn't be locked into any single runtime. Who needs it next depends on the task, not on where it happens to live. Whichever agent wakes up next should be able to read the same current state. That's the whole reason for a layer that sits outside the runtime. 4. The best part of gbrain is the page structure The first time I looked at gbrain, what got me was that every page splits into two halves. Top half is Compiled Truth, bottom half is Timeline, with a single --- line between them.

The recommended gbrain schema spells it out: every brain page has two layers. Above the line is Compiled Truth, always the current state, rewritten as new information arrives. Below the line is the Timeline, append-only, an evidence log. Ask "what's the current state," read above. Ask "what happened," read below. This fits agents well. The biggest problem with agent memory is that conclusions alone don't carry confidence, and raw logs force the agent to re-reason from scratch every time. The two halves solve exactly that. Compiled Truth is the current best judgment for the next agent to pick up fast. The Timeline is the evidence chain for audit, conflict, and rewrite. So I don't let the agent write long-term knowledge as prose. I make it write a page like this:

Top is the current conclusion. Bottom is the evidence chain. New evidence just appends to the timeline. If it changes the judgment, you rewrite the top half. That way the agent doesn't have to redo a researcher's job from the logs every time. 5. How to wire a runtime into the same brain The design I lean toward now:

The wiring can stay simple:

The next morning, no runtime has to manually load a big bundle of files. A startup rule per runtime is enough. The boot layer holds only the shortest identity, principles, and boundaries. When a person, company, project, or concept comes up, read its current state from gbrain first. When the runtime needs its own history, reach for its own memory or search tools. Headless cron jobs carry their context in explicitly. I personally run two nightly jobs back to back and review once by hand before promoting. That's just my wiring, not a requirement of the architecture. In this setup Hermes and OpenClaw are peers, each suited to different work. One is better for personal cron and delivery, the other for workspace / channel / memory-core / Dreaming. But long-term knowledge shouldn't be locked to any one side. Put it above the runtime, and once your runtimes point at the same gbrain, whether that's one or several, the long-term memory stops drifting across session restarts, machines, and runtime swaps. 6. Worth saving: where a piece of information goes The table I use now:

The two that trip people up. "Reply shorter next time" is closer to a behavior rule, so it can go into runtime memory. "Why a certain developer is sensitive to AI replies, what happened before, the current state of the relationship" is closer to a brain page. The first is how to act next time. The second is what this object is right now. A lot of people stuff both into MEMORY.md, and MEMORY.md turns to mush fast. One more simple rule: reminders go to the scheduler, not the brain. "Check the billing update next Wednesday" is a scheduled task or open loop; the gbrain page for that customer holds only the current state, the evidence, and the action boundary. OpenClaw splits these too: precise timing goes to Scheduled Tasks, periodic checks that need full context go to Heartbeat, and short-term follow-ups inferred from conversation go to its commitments. 7. Worth saving: the Memory Candidate card When a nightly review turns up something that might be worth keeping, I don't let the agent write it straight into long-term memory. It fills out this card first:

The fields can get more detailed, but these few lines are all you need the first time. This card forces the agent to answer one question: how will this actually change behavior or judgment later? If it can't answer, don't promote. 8. Worth saving: gbrain write rules These rules come straight from gbrain's recommended schema. They're the part most worth copying. Run through them before every write:

The last one matters most. Don't write "Customer A is in a hurry." Write:

Memory with scope, expiry, and an action boundary is the kind an agent can actually use. One caveat: this only writes the boundary down for the agent to read. It isn't the enforcement layer. Hard blocking still comes from runtime approval settings, sandboxing, tool policy, or scheduled-task config. 9. The three things nightly learning should produce My requirement for Nightly Learning is specific now: produce three things.

Instead of "summarize what happened today," try:

What sleep-time learning actually produces is today's experience compiled into a current state you can use tomorrow. 10. Telling whether the second brain is actually built In the end I don't count how much it stored. I look at five questions:

If those questions come back uncertain, what you're missing is probably a runtime-neutral knowledge layer. More cron or another memory plugin won't close the gap. Here's the whole thing in one line. If you only run one runtime, its own memory is enough. The moment you run Hermes and OpenClaw together, a real question shows up: who maintains the current state that belongs to no single runtime? For me, that layer is gbrain. It's still a work in progress. I haven't nailed the merge timing for two runtimes' candidates yet, so right now two nightly jobs run back to back and I review once by hand before promoting. But the direction I'm sure about: the long-term knowledge layer has to be independent of the runtime. Start here Three things to do tonight:

Don't migrate all your history up front. Get one loop running first:

Once that line runs end to end, you actually have an AI second brain. Not tied to any one runtime. Swap Hermes, swap OpenClaw, swap something else, the brain stays.

Don't let your agent wake up every morning like it's day one. And don't let each new session wake up having forgotten what the last one learned. For more agent building notes written as I build, follow @Voxyz_ai. New stuff every week, full notes at voxyz.ai/insights. Hope this was useful. Vox ❤ References Hermes Memory: persistent memory / session_search Hermes Cron: fresh session / context_from / gateway scheduler OpenClaw Memory: memory overview OpenClaw Dreaming: memory-core consolidation gbrain Schema: Compiled Truth + Timeline