Memory Brains Compared

TL;DR

The one-paragraph version

Hermes memory is two small text files, about 1,300 tokens total, pasted whole into the system prompt every turn. There is no search. When the files get full, the agent must tidy them itself, right then, or the write is refused. gbrain memory is a whole knowledge base: markdown pages as the source of truth, a Postgres cache on top, typed fact rows with confidence that decays, a graph, hybrid search, and a night shift (gbrain calls it the dream cycle) that consolidates yesterday into long-term pages while you sleep.

OpenBrain (Nate B Jones's OB1) is the simplest of the three: one Postgres table with vector search, reachable by any AI over MCP. One drawer, every AI has a key. Capture and governance are excellent; but nothing consolidates, nothing decays, and recall is a single flat semantic search the AI has to remember to run.

None of these are competitors. Hermes solves identity (who is this user, always in context). gbrain solves knowledge (everything ever said, findable on demand). OpenBrain solves sharing (one memory, every tool). A full stack wants all three shapes.

The two systems

Identity cards

hermes-agent

"The best memory stops the user repeating themselves."

Store: MEMORY.md (2,200 chars ≈ 800 tokens) + USER.md (1,375 chars ≈ 500 tokens). Free-text entries split by a § line. No IDs, no timestamps, no metadata.
Recall: None. The whole store is always in the prompt, frozen as a snapshot at session start (protects the prompt cache). Past conversations: keyword-only FTS5 search over every transcript in state.db, ~20ms, zero LLM.
Auto-capture: A silent counter: 10 user turns without a save trips a background fork that replays the chat and may only touch memory + skill tools.
Bigger brains: Swappable: one external memory provider at a time (Honcho, Mem0, Holographic…), fenced and timeout-bounded so a wedged backend can never stall a turn.
Key files: tools/memory_tool.py · agent/background_review.py · agent/memory_manager.py

gbrain

"The next Postgres for memory."

Store: A git repo of markdown pages is the system of record. Postgres/PGLite is a derived cache you can delete and rebuild. Facts live in markdown table fences (gbrain:facts:begin) mirrored to typed DB rows.
Recall: Four channels: an explicit recall op; top-10 hot facts stapled to every MCP reply; a zero-LLM reflex that points at relevant pages; and hybrid search — vector + keyword + graph, fused. P@5 49 vs ~18 for plain RAG on its own benchmark.
Auto-capture: Always-on: every page save runs an LLM extraction pass (Sonnet) that files notable claims as typed fact rows. Low-notability noise is dropped at the door.
Night shift: The dream cycle (~25 phases, 3am): promote hot facts to cold takes, extract patterns, embed, grade, purge ephemera.
Key files: src/core/facts/backstop.ts · src/core/cycle.ts · docs/architecture/system-of-record.md

The mechanism

Life of one memory

Same grid, both systems. Look at what each one has that the other doesn't: Hermes has no retrieval stage at all — the store is the prompt. gbrain has no "always in context" stage at all — everything goes through a channel.

Hermes: writes land on disk instantly but the prompt copy is frozen — a memory saved on turn 3 becomes visible next session. Overflow returns an error listing every entry: consolidate in this turn, then retry.

gbrain: markdown first, DB second — a crash between the two self-heals because the reconciler rebuilds the cache from the files. Nothing is always-in-context; all four read channels are fail-open and can never block a turn.

Similarities

Where they agree

Five real convictions in common — this is the current consensus of the field, not coincidence:

Files you own are the truth. Hermes: markdown under ~/.hermes. gbrain: a git repo, with the database demoted to a rebuildable cache (CI actually fails PRs that write derived tables directly).
The agent files its own memories — and both run an always-on capture path so nothing depends on the user saying "remember this." Hermes uses a 10-turn nudge counter; gbrain extracts on every save.
Deleting is rare and loud. Hermes refuses overflow writes instead of dropping entries, and snapshots to .bak on any suspicious drift. gbrain never deletes fact rows; forget is a visible strikethrough in the markdown with a reason, so it survives a full DB rebuild.
Memory is attack surface — and neither system ever disinfects the store. Whatever sits in memory gets read into a future prompt with full trust — so a poisoned memory is a prompt injection on a delay timer, and a leaked one is your private life in someone else's search results. Both systems accept that the store may already be dirty and scrub at the prompt boundary instead. Hermes threat-scans entries at write time and again at every load (the file on disk can be edited by things that aren't the memory tool) — a poisoned entry becomes [BLOCKED] in the prompt copy only, raw text left on disk for the user to inspect and delete. gbrain's sanitizer states the threat outright: "a claim row in the takes table contains attacker-supplied text." Every stored claim rendered into a prompt is pattern-stripped (30+ pinned jailbreak strings → [redacted]) and wrapped in <take> tags the model must treat as data, with tag-escape attempts neutralized. Behind that: private fences stripped before chunking/embedding and on remote reads (the leak direction), and dream-cycle writers caged to an allow-list of folders — the last line for an injection that fools the model anyway, not the first. True deletion of poison is a human act in both: edit the file, git revert.
Background memory work must never stall a turn. Hermes: 8s provider prefetch timeout, skip-if-busy, bounded shutdown drain. gbrain: 1.5s reflex timeout, best-effort push wrapped in its own try/catch, queue that drops-oldest at cap 100. Both fail open to "no recall," never to a hung agent.

Differences

The register, side by side

The library's own comparison keys (DECISIONS.md, Memory bank M1–M9). Read any row as: same question, opposite bet.

Question	hermes-agent	gbrain
M1 storage & index	Two text files + one SQLite (FTS5) for transcripts. All local, no server.	Markdown repo canonical; Postgres/PGLite derived cache with pgvector HNSW + tsvector. Scales to 17K-page brains.
M2 unit of memory	A free-text entry between `§` lines. That's it.	Typed rows: a fact (hot, decaying), a take (cold, attributed to a holder), a page (compiled truth + append-only timeline).
M3 schema & typing	Schemaless on purpose. No IDs, dates, confidence — the format literally cannot carry metadata.	Heavily typed: `CHECK`-constrained kinds, confidence 0–1, visibility, bi-temporal validity. New ontology dimensions are quarantined until confirmed so a hallucination can't shape context.
M4 ingestion & capture	Agent tool calls + the 10-turn background fork. Optional filing gate: `write_approval` stages writes for the user to approve.	Always-on extraction on every save through one choke point (`runFactsBackstop`). The filing gate is a notability rubric: high files now, medium waits for the night shift, low is dropped.
M5 linking & structure	None. Entries are prose; structure lives in skills instead.	Typed graph drawn automatically on every save by pattern-matching links — zero LLM tokens, never falls behind.
M6 retrieval stack	For the brain: none — always loaded. For history: keyword BM25 only, ~20ms, with hand-tuned demotions (cron chatter caused "recall blindness").	Vector + keyword + RRF fusion + graph traversal + reranker, across four channels (pull, ambient push, reflex pointers, deep search). The graph is the load-bearing wall: +31 P@5 over plain RAG.
M7 compile vs retrieve	Compile only: who-you-are compiles into `MEMORY.md`, how-to into skills. History is retrieved raw, never synthesized.	Both sides of the fork: every page keeps a pre-computed "compiled truth" section and the full retrieval stack assembles answers at query time.
M8 consolidation	At the moment of overflow, in-turn: the error message hands the agent its full inventory and says "merge now, then retry." No scheduler.	The night shift: ~25 dream-cycle phases. Consolidation clusters ≥3 day-old facts (cosine 0.85) and promotes them to takes, keeping the originals as audit trail.
M9 forgetting & pruning	Almost never. The hard cap forces triage instead of decay. Manual delete via `/journey`; reset nukes the file.	Read-time confidence decay by kind (event 7d, preference 90d, belief 365d) — no row ever mutated by aging. Purge GCs ephemera only; facts are forever.

One more fork the register doesn't ask: where the LLM spend goes. Hermes spends ~zero on memory (recall is FTS5; the fork reuses the cached prefix). gbrain spends at write time (Sonnet extraction per save) and overnight (the cycle), buying cheap, precise reads.

Judgment

Strengths and weaknesses

hermes-agent

Where it shines

The frozen snapshot. Writes are durable instantly, but the prompt stays byte-stable all session — so the prefix cache never breaks. Even the timestamp is date-only to protect it.
Error messages as a control surface. The overflow error teaches consolidation; the success response deliberately hides the entry list because echoing it made models thrash with redundant re-edits. Rare level of model-behavior craft.
Genuinely hardened I/O. Atomic writes, lock sidecars, a "file exists but unreadable ≠ empty" sentinel, external-drift refusal — each guard cites the real data-wipe bug it closed.
Trivially cheap and portable. Two files. Works identically on a $5 server.

Where it hurts

The cap is a ceiling on the user. A person with 40 durable facts can't have them; whatever doesn't fit doesn't exist, and everything that does fit is paid for on every turn whether relevant or not.
Edits match by substring, not ID — one fragile choice that spawned three separate mitigations (missing-text errors, a duplicate special case, a give-up circuit breaker).
Near-duplicates pile up. The background fork and the foreground share the store with exact-string dedup only — "prefers terse replies" and "prefers concise responses" both land, and nothing merges them.
Quiet unbounded growth at the edges: .bak files on every drift, pending-approval JSON, and state.db transcripts have no retention policy.

gbrain

Where it shines

The system-of-record rule. Markdown canonical, DB rebuildable — enforced by a CI gate and an e2e test. Backup is a git problem; even forget was refactored to survive rebuilds.
Hot/cold with a one-way bridge. Real-time facts vs attributed takes, with the docs naming "The Category Error" so nobody mixes them. Unusual design maturity.
Decay is a pure read-time function — half-lives are retunable retroactively and there's no aging sweep job to go wrong.
Push without pollution. The reflex points at pages instead of dumping bodies; volunteered context is confidence-gated ("push noise must never beat pull silence").

Where it hurts

The facts table only grows. "Never delete — audit trail" means decayed-to-zero rows sit in the index forever; purge cleans everything except facts. The long-run scaling risk.
Consolidation is cruder than the rest. Clusters pivot on the first member, promoted takes are copied (not synthesized) from one fact, and a rephrased extraction re-promotes as new. Facts that never got an embedding silently never consolidate.
The ambient reflex is proper-case/ASCII biased — misses lowercase and most non-Latin names. (The code honestly says so.)
Heavy to operate. Postgres + embeddings + a ~25-phase nightly cycle + a doc set split across four files is a lot of machine for one person's brain.

Part two

OpenBrain (OB1) vs gbrain

OpenBrain is Nate B Jones's system — the Unlock AI guide is the pitch and setup walkthrough; the actual system is open source (NateBJones-Projects/OB1, cloned into the library as ob1, HEAD 6779106). Its why is anti-silo: vendor memory is a moat — ChatGPT's memory lives in ChatGPT, Claude's projects live in Claude, and "a vendor that remembers you is a vendor that's hard to leave." OB1's answer: memory is just a database problem — a table that stores what you said, an index that finds it by meaning, an API any client can call — so own it, and "your context stops being a switching cost and starts being an asset that compounds." Same ingredients as gbrain — Postgres, pgvector, MCP, LLM extraction at the door — arranged around the opposite answer to "where does the truth live."

The two systems

Identity cards

OB1 / OpenBrain

"One brain. All of them."

Store: One Postgres table (thoughts) on Supabase's free tier: content + 1536-d embedding + metadata JSON. The database is the truth. Files only exist if you run the backup script.
Recall: Pull-only, over MCP: the AI must decide to call search_thoughts — flat cosine top-10, threshold 0.5. No always-loaded profile, no push. A "live retrieval" skill exists precisely because nothing reads back on its own.
Auto-capture: Deliberately no daemon — "a behavioral cue, not a timer." Client-side skills and companion prompts tell each AI when to save; capture embeds + extracts people/topics/type with gpt-4o-mini. 52 import recipes for bulk (Obsidian, ChatGPT exports, Gmail…).
Agent memory: A governed sidecar: provenance labels, a human review queue, recall traces — and a DB CHECK that makes agent-written memory evidence, not instruction until a human confirms it.
Setup: ~30 minutes, zero code: eight paste-and-click steps, four SQL commands, two accounts (Supabase free tier + ~$5 of OpenRouter credits). Built in the open — community contributions pass an automated review agent, then a human maintainer.
Key files: server/index.ts (643 lines — the whole runtime) · schemas/agent-memory/schema.sql · docs/01-getting-started.md

gbrain (recap — full treatment in part one)

"The next Postgres for memory."

Store: Markdown repo is the truth; Postgres is a cache you can delete and rebuild. Typed rows: hot facts (decaying), cold takes (attributed), pages with pre-computed "compiled truth."
Recall: Four channels, push and pull: recall op, top-10 hot facts stapled to every MCP reply, a reflex that points at relevant pages, and hybrid vector + keyword + graph search.
Auto-capture: Always-on: every save runs Sonnet extraction through one choke point, with a notability filter at the door.
Night shift: The dream cycle, ~25 phases at 3am: consolidate facts → takes, embed, grade, purge ephemera.
Key files: src/core/facts/backstop.ts · src/core/cycle.ts · docs/architecture/system-of-record.md

The mechanism

One flat drawer — and the truth, inverted

Left: OB1's whole loop on the same grid as part one — notice what's missing versus gbrain: no night-shift loop, and no push channels. Right: the single deepest difference between the two.

OB1: the write trigger lives in client-side skills ("a behavioral cue, not a daemon"), and every read is the model choosing to search. Nothing runs on a schedule; dedup, enrichment, and review are scripts and a human queue.

The inversion: same ingredients, opposite bet on C1 (source of truth). gbrain demotes the database and pays for it in reconciler machinery; OB1 promotes the database and pays for it in backup discipline.

Similarities

Where they agree

Same substrate, same plug. Postgres + pgvector + typed metadata, exposed over MCP so any body (Claude, ChatGPT, Cursor…) can use the brain. Both are brains-without-a-body by design.
An LLM works the door. Both extract structure at capture time: gbrain has Sonnet judge notability and file typed facts; OB1 has gpt-4o-mini pull people, topics, dates, and a type into metadata.
Dedup at write time. gbrain: cosine ≥ 0.95 then an LLM classifier. OB1: normalize + SHA-256 fingerprint upsert (exact match only — rephrasings get through).
Deeply suspicious of agent-written memory. gbrain quarantines novel ontology dimensions so a hallucination can't shape context. OB1 goes further: "agent memory is evidence, not instruction" is a database CHECK — an agent literally cannot promote its own note to instruction-grade without a human confirming it.
History is append-only. gbrain forgets by visible strikethrough with a reason. OB1's audit table has no UPDATE/DELETE grants at all — even a buggy function can't rewrite history.
A typed entity graph on top — always-on and zero-LLM in gbrain; an optional worker sidecar in OB1.

Differences

The register, side by side

Same M1–M9 keys as part one, gbrain on the left this time.

Question	gbrain	OB1 / OpenBrain
M1 storage & index	Markdown repo canonical; Postgres/PGLite derived cache (pgvector HNSW + tsvector). Local or hosted.	One Supabase Postgres table is the brain: content, 1536-d embedding, metadata JSON, HNSW index. Free tier. No file layer.
M2 unit of memory	Typed rows: a fact (hot, decaying), a take (cold, attributed), a page (compiled truth + timeline).	A "thought": one idea, free text + JSON metadata. One-idea-per-row is a prompt convention, not a schema rule — an atomizer recipe exists to retro-fix violations. Sharp domain facts (calendar, pantry, CRM, job hunt) skip `thoughts` entirely and live in six typed extension tables — same database, so the meal planner can see the family calendar.
M3 schema & typing	`CHECK`-constrained kinds, confidence, visibility, bi-temporal validity; new ontology dimensions quarantined until confirmed.	Schemaless core, plus a heavily governed agent-memory sidecar (8 types × provenance × review × use-policy). Three type vocabularies in the repo disagree with each other.
M4 ingestion & capture	Always-on: every save runs extraction through one choke point; notability filter drops noise at the door.	Deliberately no daemon — "a behavioral cue, not a timer." Skills tell each AI when to call `capture_thought`; 52 import recipes for bulk; a regex gate blocks secrets and transcript dumps from agent write-back.
M5 linking & structure	Typed graph drawn automatically on every save, zero LLM tokens.	Optional entity-graph sidecar (entities, edges, extraction queue + worker). Off in the stock build.
M6 retrieval stack	Vector + keyword + RRF fusion + graph + reranker across four channels, push and pull. P@5 49 on its own benchmark.	One flat cosine top-10, pull-only. The SQL supports metadata filtering — the stock tool never passes it. Thresholds disagree per surface (0.7 SQL default, 0.5 MCP, 0.25 agent API). No rerank.
M7 compile vs retrieve	Both: pre-computed "compiled truth" on every page and the full retrieval stack.	Pure retrieve. "You don't need to organize them — the vector search handles retrieval by meaning." A wiki-compiler recipe can compile pages, but it's manual, opt-in.
M8 consolidation	The night shift: ~25 dream-cycle phases promote day-old fact clusters into takes, nightly, automatically.	No scheduler at all. Maintenance is the human: dedup scripts, enrichment runs, a review queue, and a "weekly review" prompt you run yourself.
M9 forgetting & pruning	Read-time half-life decay by kind; forget = strikethrough that survives rebuilds; purge GCs ephemera.	Nothing expires by default. A recency-blend search function ships with weight 0 (off); `stale_after`/`ttl_days` columns are written and never enforced. No sweeper exists.

Cost fork: OB1 runs on ~$0.10–0.30/month of tokens — its real ceiling is Supabase's 500K free-tier invocations, which one measured multi-connector setup burned through at 1.8M/week before the optimization recipe. gbrain spends real LLM money at write time (Sonnet per save) and every night.

Judgment

Strengths, weaknesses, and which shape when

OB1 / OpenBrain

Where it shines

Radically small and ownable. A 643-line server + one table + one SQL function is the whole core. A non-coder rebuilds it from the guide in ~30 zero-code minutes on free tiers. Nothing is a black box.
The best agent-trust model of all three brains. Provenance labels, a human review queue, and recall traces that record what was recalled, at what rank, and whether the agent actually used it — so you can tell retrieval failure from model failure. Most systems can't.
Secrets can't become memories. Private keys, API keys, credential-shaped strings, and transcript dumps are rejected before storage, with an audit event.
Genuinely portable. Plain SQL + JSON export, documented escape hatches for local-only, Ollama embeddings, and non-Supabase Postgres — the adapter boundary was written down before a second adapter existed.

Where it hurts

Recall is the weak half — and the repo says so. Flat kNN with the metadata filter never wired up and no rerank; the agent-memory recall shortlists over the whole thoughts table, so it can miss real memories — or, on zero vector hits, silently return the 100 most recent with no relevance filter.
Capture isn't atomic. Insert row, then update embedding — a crash between the two leaves a thought that search can never find.
No lifecycle. Nothing consolidates, decays, or forgets on its own. The documented end state is an 89K-row flat drawer where a stats call scans every row.
One shared access key gates everything — and the documented Claude/ChatGPT setup passes it in the URL.

Head to head

Which shape, when

Opposite truths. gbrain trusts files and treats the DB as disposable; OB1 trusts the DB and makes files a manual export. For a brain you want in ten years, gbrain's bet is safer. OB1's is dramatically simpler.
Who is the librarian. gbrain automates it — the night shift consolidates, decays, and purges while you sleep. In OB1, the librarian is you: the review queue, the dedup scripts, the weekly-review prompt.
OB1 wins on: approachability, multi-AI sharing today, and agent-memory governance (the evidence-not-instruction rail is stronger than anything in gbrain).
gbrain wins on: retrieval precision (a measured +31 P@5 from its graph vs OB1's flat kNN), memory lifecycle (decay + consolidation), and the typed hot/cold model.
Rule of thumb: OB1 is a weekend build every AI can use on Monday. gbrain is the brain that's still good in year three.

So what

If you're building your own

Don't pick one — they're layers. Hermes is the pocket: tiny, curated, always on you. gbrain is the archive: everything, findable. OpenBrain is the socket: one plug every AI fits. The composite shape for a real stack: a capped always-in-prompt identity note (Hermes-style) on top of a markdown-canonical retrievable store with a night shift (gbrain-style), exposed to every tool over MCP with OB1-style trust rails on anything an agent writes.

Steal from Hermes: the frozen-snapshot rule (memory writes must never break the prompt cache mid-session), the hard cap with overflow-refusal (forces curation better than any prompt asking nicely), and error-message design as agent training.

Steal from gbrain: markdown as system of record with the DB as a disposable cache, the hot/cold split with one-way promotion, read-time decay as a pure function, and confidence-gated push. And learn from its scar: give every memory row an ID and a timestamp from day one — Hermes's § format can't retrofit metadata, and half its fragility traces to that.

Steal from OpenBrain: the evidence-not-instruction CHECK and human review queue for anything an agent writes back; recall traces (log what was recalled, at what rank, and whether it got used — the only way to debug memory later); and the write-back filter that keeps secrets and raw transcripts out of durable storage. And learn from its scar: ship the recall side with the same care as capture, or the drawer just fills.

Sources: source-level reads of hermes-agent (HEAD 2446c8b), gbrain, and ob1 (NateBJones-Projects/OB1, HEAD 6779106) on 2026-08-10; cross-checked 2026-08-11 against the Unlock AI "Open Brain" guide page (the pitch + setup walkthrough for the same system). Terms per the library glossary — repo's own word in parentheses on first use. Companion atlases: hermes-agent-atlas, gbrain-atlas.

Hermes keeps a sticky note.
gbrain keeps a library.
OpenBrain keeps a shared drawer.

The one-paragraph version

hermes-agent vs gbrain

Identity cards

hermes-agent

gbrain

Life of one memory

Where they agree

The register, side by side

Strengths and weaknesses

hermes-agent

Where it shines

Where it hurts

gbrain

Where it shines

Where it hurts

OpenBrain (OB1) vs gbrain

Identity cards

OB1 / OpenBrain

gbrain (recap — full treatment in part one)

One flat drawer — and the truth, inverted

Where they agree

The register, side by side

Strengths, weaknesses, and which shape when

OB1 / OpenBrain

Where it shines

Where it hurts

Head to head

Which shape, when

If you're building your own