Hermes vs nanobot memory comparison

Hermes vs Nanobot: Memory and Long-Term Memory Implementation Comparison

Scope

This note compares the actual memory implementations in hermes-agent and nanobot, with emphasis on:

• persistent curated memory
• long-term recall across sessions
• user-profile memory
• transcript persistence and search
• consolidation and compaction behavior
• durability, safety, and operational tradeoffs

This is implementation-focused, not README-level feature marketing.

Executive Summary

Hermes has a layered memory architecture:

1. Curated persistent memory in MEMORY.md
2. Separate persistent user-profile memory in USER.md
3. SQLite-backed full transcript storage with FTS5 search
4. A dedicated session_search recall tool that summarizes prior sessions on demand
5. Optional Honcho-based user modeling that builds a richer long-term representation of the user over time

Nanobot has a lighter, file-centric memory architecture:

1. One curated long-term memory file at workspace/memory/MEMORY.md
2. JSONL session history under workspace/sessions/
3. LLM-driven consolidation of old turns into memory files
4. Optional hybrid BM25/vector retrieval over docs and memory files
5. Session-end and pre-compaction archival into dated markdown files

Bottom line: Nanobot is stronger at context-pressure-driven archiving and simple inspectable memory files. Hermes is substantially stronger at memory separation, cross-session recall, user modeling, concurrency safety, and long-term continuity.

Hermes Memory Implementation

1. Curated persistent memory is split by purpose

In hermes-agent/tools/memory_tool.py, Hermes stores:

• MEMORY.md for agent/environment/project notes
• USER.md for user preferences, behavior, expectations, and profile facts

This split matters. Hermes can treat “facts about the user” as a first-class memory type instead of mixing them with project notes and environment facts.

2. Memory is managed as bounded entries, not as a monolithic blob

Hermes MemoryStore stores entries separated by a delimiter and supports:

• add
• replace
• remove

It also enforces separate character budgets for agent memory and user memory. This gives Hermes a targeted mutation model instead of requiring a full-file rewrite for every memory update.

3. Prompt injection uses a frozen snapshot

Hermes loads memory from disk at session start, captures _system_prompt_snapshot, and injects that frozen snapshot into the system prompt. Mid-session memory writes go to disk immediately, but they do not mutate the already-injected system prompt until the next session.

This is a deliberate design for prefix-cache stability. It reduces system-prompt churn and avoids changing the model’s base context every time memory is edited.

4. Memory writes are safer and more concurrent-friendly

Hermes memory writes use:

• file locks
• atomic temp-file + rename persistence
• reload-under-lock before mutation
• deduplication

It also scans memory content for prompt injection and exfiltration patterns before allowing memory to be stored.

5. Transcript memory is a separate durable subsystem

In hermes-agent/hermes_state.py, Hermes uses state.db with:

• sessions table
• messages table
• FTS5 messages_fts
• parent session chains
• reasoning field persistence on assistant messages

This is not just logging. It is a searchable recall substrate.

6. Cross-session recall is transcript-native

In hermes-agent/tools/session_search_tool.py, Hermes:

1. searches transcripts with FTS5
2. groups results by session
3. resolves parent/child session lineage
4. loads relevant conversations
5. truncates around matches
6. summarizes top sessions for the current query

This gives Hermes true “what did we do before?” recall, grounded in full transcripts rather than only previously extracted summaries.

7. Long-term user modeling exists beyond file memory

With Honcho enabled, Hermes adds another layer:

• peer card / user profile retrieval
• semantic search over user context
• dialectic question answering over prior context
• explicit conclusion writing back to user memory
• background prefetch of continuity context for the next turn

This is qualitatively different from plain file memory. Hermes can build a long-lived representation of the user and use it as a recall and personalization system.

Nanobot Memory Implementation

1. Persistent curated memory is a single file

In nanobot/agent/memory.py, Nanobot stores long-term memory in:

• workspace/memory/MEMORY.md

ContextBuilder injects that file into the system prompt as ## Long-term Memory.

2. Consolidation is full-file LLM rewrite

Nanobot’s MemoryStore.consolidate() sends a message chunk plus the current MEMORY.md to an LLM and forces a virtual save_memory tool call. The model returns the full updated memory document, which replaces the old file.

This means Nanobot memory updates are:

• coarse-grained
• model-mediated
• dependent on full-memory regeneration

There is no built-in targeted add/replace/remove model for curated memory.

3. Nanobot is strong at archival and compaction flows

Nanobot has multiple memory-adjacent flows in nanobot/agent/memory.py:

• SessionMemoryWriter: writes dated session summaries like memory/YYYY-MM-DD-slug.md
• MemoryFlusher: extracts durable facts before context compaction into daily files
• MemoryConsolidator: chooses boundaries, archives older messages, and manages consolidation policy

This is a practical context-management pipeline. Nanobot tries hard not to lose information when the prompt grows too large.

4. Failure fallback is explicit

If consolidation repeatedly fails, Nanobot raw-archives the original messages into dated files like memory/YYYY-MM-DD-raw-archive.md.

This is a good operational safeguard. Even when summarization degrades, the data is not silently lost.

5. Session persistence is append-only JSONL, not searchable recall

In nanobot/session/manager.py, sessions are stored in JSONL files. Important details:

• message history is append-only
• last_consolidated marks how much history has already been summarized to memory files
• consolidation does not rewrite the in-memory message list returned by get_history()

This is simple and inspectable, but it is not a transcript recall system equivalent to Hermes state.db + FTS5.

6. Retrieval is file-centric, not transcript-centric

In nanobot/agent/vector_memory.py, Nanobot can index:

• workspace/docs/<project>/...
• memory markdown files
• curated memory content

It supports hybrid BM25 + vector search using SQLite plus optional sqlite-vec. This is useful, but it retrieves indexed files and chunks, not prior conversation sessions as first-class recall objects.

Detailed Comparison

Dimension	Hermes	Nanobot	Assessment
Curated long-term memory	Split into MEMORY.md and USER.md	Single memory/MEMORY.md	Hermes is more expressive and easier to keep clean
Memory update model	Targeted add/replace/remove	Full-file rewrite via LLM consolidation	Hermes is safer and more controllable
Prompt injection strategy	Frozen snapshot per session	Re-read current memory when building prompt	Hermes is better for prompt stability
Memory safety	Injection/exfiltration scanning before save	No equivalent memory-content screening found	Hermes is safer
Write durability	Atomic rename + locking	Direct file write for curated memory	Hermes is more robust under concurrency/failure
Session persistence	SQLite DB with schema and metadata	JSONL files per session	Hermes is more scalable and queryable
Transcript search	FTS5 over all messages	No transcript-level search	Major Hermes advantage
Cross-session recall	session_search summarizes prior sessions	Only file retrieval from memory/docs	Major Hermes advantage
User-profile memory	Dedicated USER.md plus Honcho profile tools	No separate user-profile store	Major missing capability in Nanobot
Long-term personalization	Honcho peer cards, search, conclusions, context	None comparable	Major missing capability in Nanobot
Context-pressure handling	Session compression and lineage chains	Strong memory flushing/consolidation/archive pipeline	Nanobot is stronger here
Failure fallback	DB persistence plus fallback behaviors in recall paths	Raw archive markdown fallback	Nanobot has a clear simple fallback story
Retrieval granularity	Session-level and user-model level	File/chunk level	Hermes supports richer continuity

What Nanobot Is Missing Relative to Hermes

The list below is scoped only to memory and long-term memory.

Ratings:

• Impact: how much the feature improves continuity, recall quality, and user experience
• Difficulty: rough implementation complexity inside Nanobot
• Priority: recommended order for Nanobot

Missing feature in Nanobot	What Hermes has	Why it matters	Impact	Difficulty	Priority
Separate user-profile memory store	USER.md distinct from MEMORY.md	Prevents user preferences from being mixed with project facts; improves personalization	5/5	2/5	High
Fine-grained memory mutations	add, replace, remove on memory entries	Avoids fragile full-document rewrites and makes memory edits auditable	4/5	2/5	High
Frozen per-session memory snapshot	_system_prompt_snapshot pattern	Keeps prompt stable and cache-friendly while still allowing durable writes	4/5	3/5	High
Memory-content safety scanning	prompt-injection and exfiltration checks before save	Reduces risk of memory becoming an attack surface	4/5	2/5	High
Atomic, lock-safe memory persistence	file locks + atomic replace	Reduces corruption/race risk in multi-process or interrupted writes	4/5	2/5	High
Searchable transcript store	SQLite state.db with FTS5 over all messages	Enables actual recall of past work instead of relying on extracted summaries	5/5	4/5	High
Session-level recall tool	session_search over transcript DB	Lets the agent answer “what did we do before?” with full-session grounding	5/5	4/5	High
Parent/child session lineage	parent_session_id chains	Preserves continuity through compression, delegation, or split sessions	3/5	3/5	Medium
Reasoning-aware session persistence	reasoning fields stored with messages	Preserves richer assistant state across resumed sessions	3/5	3/5	Medium
Dedicated user-model layer	Honcho peer cards and peer representation	Moves beyond notes into structured long-term understanding of the user	5/5	5/5	Medium-High
Semantic user-context query tools	honcho_profile, honcho_search, honcho_context	Gives the agent low-cost ways to ask for user continuity context	4/5	5/5	Medium
Explicit conclusion writing for user facts	honcho_conclude	Makes preference capture deliberate instead of incidental	4/5	4/5	Medium
Background continuity prefetch	prefetch next-turn Honcho context and synthesis	Improves continuity without always paying recall cost at response time	3/5	4/5	Low-Medium
Transcript recall separate from curated memory	prompt guidance separates memory vs session recall vs skills	Reduces pressure to overload MEMORY.md with temporary session outcomes	4/5	3/5	High

Important Tradeoffs

Where Nanobot is better

• Nanobot has a clearer “context got too large, preserve the important parts now” pipeline.
• The dated markdown files are easy to inspect by hand.
• Raw archive fallback is simple and operationally reliable.
• Hybrid retrieval over docs plus memory files is useful for RAG-style workflows.

Where Hermes is better

• Hermes separates memory types instead of mixing them.
• Hermes treats transcripts as searchable memory, not just logs.
• Hermes supports long-term continuity even when facts were never manually promoted into MEMORY.md.
• Hermes has a stronger durability and safety model around persistent memory.
• Hermes can build a user representation instead of only storing notes about the user.

Core architectural difference

Hermes treats memory as a stack of distinct systems:

• curated fact memory
• transcript memory
• procedural memory (skills)
• optional user-model memory

Nanobot treats memory primarily as:

• one curated memory file
• a set of archival memory documents
• optional vector retrieval over files

That makes Nanobot easier to reason about, but much weaker at long-term continuity across sessions.

Recommended Roadmap for Nanobot

Phase 1: Highest ROI

1. Add USER.md as a separate store from MEMORY.md.
2. Replace full-file-only curated memory updates with entry-based add/replace/remove.
3. Add atomic writes and memory-content safety scanning.
4. Separate prompt-injected curated memory from session archive files conceptually and in tooling.

Phase 2: Real cross-session recall

1. Add a SQLite session store alongside or instead of JSONL.
2. Index session messages with FTS5.
3. Build a session_search equivalent that summarizes prior sessions for a query.
4. Preserve session lineage when compaction or splitting happens.

Phase 3: Long-term personalization

1. Add a first-class user-model layer.
2. Add profile retrieval and semantic user-context tools.
3. Add explicit “conclude/save fact about user” behavior.
4. Consider turn-end prefetch of continuity context.

Bottom-Line Assessment

If the goal is simple, inspectable memory plus aggressive context-compaction hygiene, Nanobot already has a decent foundation.

If the goal is strong long-term continuity, cross-session recall, and persistent user understanding, Nanobot is materially behind Hermes.

The single biggest missing capability is not “better summarization.” It is the absence of transcript-native recall and a separate user-profile memory model.

Main Source Files Reviewed

Hermes:

• hermes-agent/tools/memory_tool.py
• hermes-agent/hermes_state.py
• hermes-agent/tools/session_search_tool.py
• hermes-agent/agent/prompt_builder.py
• hermes-agent/honcho_integration/session.py
• hermes-agent/tools/honcho_tools.py
• hermes-agent/run_agent.py

Nanobot:

• nanobot/agent/memory.py
• nanobot/agent/context.py
• nanobot/session/manager.py
• nanobot/agent/vector_memory.py
• nanobot/agent/loop.py