Hermes Agent Memory System: How Persistent AI Memory Actually Works

You know the drill. You open a chat with an AI agent, explain your project, share your preferences, get some work done, and close the tab. Come back the following week and it’s like talking to a stranger — all context gone, every preference forgotten, the project re-explained from scratch.

This isn’t a bug. It’s how Large Language Models work by design. They’re stateless: each request is independent, each response generated from whatever prompt you send right now, with no memory, no history, and no continuity beyond the tokens in the current context window.

For single-turn interactions, that’s fine. Ask a question, get an answer, move on. But for agents — systems that are supposed to do things across sessions, learn from mistakes, and evolve with you — statelessness is a hard architectural limit. It’s one of the central unsolved problems in self-hosted AI systems.

The industry has tried to solve this. LangChain added memory modules. OpenAI introduced assistants with threads. Frameworks like Letta, Zep, and Cognee built entire architectures around persistent memory. Databricks published on “memory scaling” — the idea that agent performance improves with accumulated experience. Dedicated benchmark papers, episodic memory surveys, and a rapidly growing ecosystem of tools have all emerged since 2024 to address what is increasingly recognised as one of the central unsolved problems in agentic AI.

Most of these approaches share a common problem: they treat memory as an afterthought — a database you query, a context window you stuff, a retrieval system that adds latency and noise rather than clarity.

Hermes Agent takes a fundamentally different approach. Memory isn’t something the agent retrieves when needed. It’s something the agent is at all times — built into the system prompt, curated, bounded, and always active. It’s small enough to be fast, structured enough to be useful, and disciplined enough to know what to forget.

This article explains exactly how that works.

Part 1: The AI Agent Memory Problem

Why “Just Add Context” Doesn’t Scale for Agents

The obvious solution to stateless AI is to add context. Attach the previous conversation. Include the project documentation. Send the entire history.

For a while, that works. You’ve got a 128K context window. You can fit a lot of text in there.

But context isn’t memory — there’s a real and important difference between them. Context is everything you’re shown right now; memory is what you actively keep and carry forward.

Context has no curation. It’s a dump: as it grows, the model has to process thousands of tokens of irrelevant history to find the one fact it needs. That costs tokens and money, compounds latency, and eventually hits the ceiling.

Memory is curated. It’s the distillation of experience into something compact and actionable. It doesn’t grow indefinitely — it consolidates, updates, and forgets.

Human memory works the same way. You don’t remember every conversation you’ve ever had. You remember the parts that matter: who you’re talking to, what they care about, what you’ve agreed on, what you’ve learned. The rest is either forgotten or searchable when you need it.

The Research Landscape

The AI agent memory space has exploded since 2024, with dedicated benchmark suites, a growing research literature, and a measurable performance gap between different architectural approaches. Here’s where things stand.

Letta (formerly MemGPT) was one of the earliest frameworks to treat persistent memory as a first-class concern, reaching 21.7K GitHub stars. It uses an OS-inspired three-tier model: core memory (small, always in context), recall memory (searchable conversation history), and archival memory (long-term cold storage). The insight that not all memory is equal was correct. The implementation, however, requires agents to run entirely inside the Letta runtime — adopting it means adopting the whole platform, not just a memory layer.

Zep / Graphiti focuses on conversational memory with temporal entity tracking — facts carry validity windows so the graph knows when something was true. It’s strong for chatbots that need relationship graphs, less suited for autonomous agents tracking environment facts and project conventions.

Cognee is built for knowledge extraction from documents and structured data, with 30+ ingestion connectors and a knowledge graph backend. It excels at institutional knowledge and RAG pipelines but is less focused on personal agent memory. See self-hosting Cognee with local LLMs for a practical setup guide.

Hindsight does knowledge graph-based recall with entity relationships and a unique reflect synthesis tool that performs cross-memory synthesis — combining multiple memories into new insights. It’s among the top performers on agent memory benchmarks and is available as a memory provider for Hermes Agent.

Mem0 handles memory extraction server-side via LLM analysis, requiring minimal configuration. The Mem0 research paper, published at ECAI 2025 (arXiv:2504.19413), benchmarked ten distinct approaches to AI memory and validated the selective extraction approach — storing discrete facts, deduplicating, and retrieving only what’s relevant. Mem0 has grown to approximately 48K GitHub stars and supports 21 framework integrations. The trade-off is cloud dependency and cost.

Databricks’ memory scaling research introduced the concept that agent performance improves with accumulated experience. Their architecture holds system prompts, enterprise assets, and episodic/semantic memories scoped at organization and user level, validating the idea that memory quality matters as much as model capability.

The common thread across most frameworks is that they treat memory as a retrieval problem: store it somewhere, query it when needed, inject it into context. Hermes does the opposite — memory isn’t retrieved on demand, it’s injected at session start and always present. Always active, always available, curated enough to stay useful.

Part 2: Architecture — Two Files, One Brain

Hermes Agent’s built-in memory system lives in two files.

• ~/.hermes/memories/MEMORY.md — Agent’s personal notes (2,200 chars, ~800 tokens)
• ~/.hermes/memories/USER.md — User profile (1,375 chars, ~500 tokens)

That’s the entire persistent memory surface: two files, under 3,600 characters total, fewer than 1,300 tokens. It looks deliberately small because it is — and that’s exactly the design intent.

MEMORY.md: The Agent’s Notes

This is where the agent stores everything it learns about its environment, the project, tools, conventions, and lessons learned. Here’s what it looks like:

User's project is a Go microservice at ~/code/gateway using gRPC + PostgreSQL
This machine runs Ubuntu 22.04, has Docker and kubectl installed
User prefers snake_case for variable names and avoids camelCase

These aren’t logs. They’re facts. Dense, declarative, information-packed. No timestamps, no fluff, no “on January 5th the user asked me to…”

USER.md: The User Profile

This is where the agent stores everything it knows about you.

User is a full-stack developer comfortable with TypeScript, Go, and Python.
User prefers snake_case for variable names and avoids camelCase.
User primarily uses Linux Ubuntu 22.04.
User deploys to AWS using Terraform.

Identity, role, preferences, technical skills, communication style, pet peeves. The stuff that makes the agent respond differently to you than to anyone else.

The Frozen Snapshot Pattern

At session start, both files are loaded from disk and injected as a frozen block into the system prompt. Here’s what it looks like:

══════════════════════════════════════════════
MEMORY (your personal notes) [7% — 166/2,200 chars]

User’s project is a Go microservice at ~/code/gateway using gRPC + PostgreSQL § This machine runs Ubuntu 22.04, has Docker and kubectl installed § User prefers snake_case for variable names and avoids camelCase §

══════════════════════════════════════════════ USER PROFILE (who the user is) [8% — 110/1,375 chars] ══════════════════════════════════════════════ User is a full-stack developer comfortable with TypeScript, Go, and Python. § User prefers snake_case for variable names and avoids camelCase. §

The format uses headers, usage percentages, character counts, and `§` (section sign) delimiters. Entries can be multiline. It's designed to be parseable by the model while remaining human-readable.

Why frozen? [Prefix caching](https://www.glukhov.org/llm-performance/). The system prompt is the same across every turn in a session. By keeping memory static after session start, the model can cache the prefix computation and only process the variable parts — the conversation. This is a significant performance optimization. You're not re-computing attention over the same memory tokens on every turn.

Changes made during a session persist to disk immediately, but they only appear in the system prompt at the next session start. Tool responses always show the live state, but the model's "mind" doesn't change mid-session. This prevents the model from chasing its own tail — updating memory and then reacting to its own update in the same conversation.

### Character Limits as a Feature

2,200 characters. 1,375 characters. These aren't arbitrary limits. They're design constraints that force curation.

Unlimited memory is a liability. It encourages dumping everything in, never consolidating, and eventually becoming noise. Bounded memory forces the agent to be selective. What's actually important? What will I need again? What can be compressed without losing meaning?

When memory is full, the agent doesn't just fail silently. It gets an error with current entries and usage, then follows a workflow:

1. Read current entries from error response
2. Identify removable or consolidatable entries
3. Use `replace` to merge related entries into shorter versions
4. Add the new entry

This is how memory stays useful. It's not a database. It's a curated collection of facts that matter.

### Security: Prompt Injection Scanning

Every memory entry is scanned before acceptance. The system blocks prompt injection attempts, credential exfiltration, SSH backdoors, and invisible Unicode characters.

Memory is also deduplicated. Exact duplicate entries are rejected automatically. This prevents adversaries from trying to inject malicious content through repeated submissions.

---

## Part 3: When Memory Fires — Triggers & Decisions

The most common question about Hermes Agent's memory is when it actually saves something.

The answer is: constantly, but selectively. The agent manages its own memory via the `memory` tool, and the decision to save is driven by a combination of explicit signals and implicit patterns.

### Writing Triggers: When Does the Agent Decide to Save?

The agent saves memory proactively. It doesn't wait for you to ask. Here's what triggers it.

**User corrections.** When you correct the agent, that's a signal to remember. "Don't do that again." "Use this instead." "Remember this." These are explicit instructions to update memory.

Example: you ask the agent to configure a Python environment. It suggests `pip`. You say "I use `poetry` for everything." The agent saves: `User prefers using the 'poetry' package manager for all Python projects.`

**Discovered preferences.** The agent observes patterns and infers preferences. If you consistently use a certain tool, framework, or workflow, it gets saved.

Example: after seeing you use `poetry` multiple times across different projects, the agent saves it as a preference.

**Environment facts.** Things about the machine, the project, the tools installed. These are discovered through exploration and saved as facts.

Example: the agent checks what's installed and saves: `This machine runs Ubuntu 22.04, has Docker and kubectl installed.`

**Project conventions.** How the project is structured, what tools it uses, what patterns it follows. These are discovered through code inspection and saved.

Example: `User's project is a Go microservice at ~/code/gateway using gRPC + PostgreSQL.`

**Completed complex workflows.** After completing a task that took 5+ tool calls, the agent considers saving the approach as a skill or at least noting what worked.

**Tool quirks and workarounds.** When the agent discovers something non-obvious about a tool, API, or system — a limitation, a workaround, a convention — it saves it.

**What gets skipped:**

- Trivial or obvious information
- Things easily re-discovered
- Raw data dumps
- Session-specific ephemera
- Information already in context files (SOUL.md, AGENTS.md)

### Reading Triggers: When Does the Agent Recall?

Memory isn't retrieved — it's always there. But there are different levels of access.

**Session start (automatic).** MEMORY.md and USER.md are injected into the system prompt. The agent has them from the first token. No query needed, no latency, no tool call. This is the core memory — always active.

**`session_search` (on-demand).** When the agent needs to find something from past conversations that isn't in core memory, it uses the `session_search` tool. This queries SQLite (`~/.hermes/state.db`) with FTS5 full-text search and Gemini Flash summarization.

Example: you ask "Did we discuss Docker networking last week?" The agent searches session history and returns a summary of the relevant conversation.

**External provider tools (when configured).** When an external memory provider is active, the agent has additional tools available: `honcho_search`, `hindsight_recall`, `mem0_search`, etc. These are used when the agent determines that external context is needed.

### The Decision Tree

Here's how the agent weighs "is this worth remembering?":

Is this a correction or explicit instruction? YES → Save to memory NO → Is this a preference or pattern? YES → Save to user profile NO → Is this an environment fact or convention? YES → Save to memory NO → Is this easily re-discovered? YES → Skip NO → Is this session-specific? YES → Skip NO → Save to memory

The agent doesn't overthink this. It saves proactively, consolidates when full, and trusts the character limits to keep things tight.

---

## Part 4: Internal Memory vs. External Knowledge Bases

This is where confusion often happens. Hermes Agent has *internal memory* (MEMORY.md, USER.md, external providers) and *external knowledge bases* (LLM Wiki, Obsidian, Notion, ArXiv, filesystem), and they serve completely different roles. This is similar to the distinction between [retrieval-augmented generation](https://www.glukhov.org/rag/) pipelines and agent working memory — external retrieval is good for deep knowledge lookups, not for carrying identity and preferences. Internal memory is the agent's brain — always active, curated, carried into every session. External knowledge bases are its library — vast reference resources consulted on demand.

### The Distinction

**Internal Memory (the brain):**

- Small, persistent, injected into system prompt
- Contains: user preferences, agent conventions, immediate lessons
- Always "in mind" during conversation
- Curated, bounded, actively managed
- Examples: MEMORY.md, USER.md, Honcho, Hindsight, Mem0

**External Knowledge Bases (the library):**

- Vast, reference-only, accessed on-demand
- Contains: documents, papers, code, notes, databases
- Accessed via tools when needed
- Not "remembered" — looked up
- Examples: LLM Wiki, Obsidian, Notion, ArXiv, filesystem, GitHub

### How They Relate

The agent *accesses* external bases via tools when needed. It doesn't "remember" them — it looks them up.

**LLM Wiki (llm-wiki):** Karpathy's interlinked Markdown knowledge base for building and querying domain knowledge. The agent uses the `llm-wiki` skill to read, search, and query it. It's a reference resource, not memory.

**[Obsidian](https://www.glukhov.org/knowledge-management/tools/obsidian-for-personal-knowledge-management/):** Personal note vaults with bidirectional links. The agent uses the `obsidian` skill to read, search, and create notes. Obsidian is part of the broader [personal knowledge management](https://www.glukhov.org/knowledge-management/) ecosystem that Hermes can tap into as a library resource.

**Notion/Airtable:** Structured databases and wikis accessed via API. The agent queries them when needed.

**ArXiv:** Academic paper repositories. The agent searches and extracts papers when researching a topic.

**Filesystem:** Project code, documentation, configurations. The agent reads files when working on a project.

### The Distillation Pattern

Here's the key insight: critical insights from external bases can be *distilled* into internal memory.

Example: the agent reads a paper from ArXiv about memory scaling for AI agents. It doesn't save the entire paper to memory. It saves the key takeaway: `Memory scaling: agent performance improves with accumulated experience through user interaction and business context stored in memory.`

The external resource is vast. The internal memory is the distillation.

### When to Use Which

**Internal memory for:**

- "Who am I helping?"
- "What do they prefer?"
- "What did we just learn?"
- "What's the project setup?"
- "What tools are available?"

**External knowledge bases for:**

- "What's the latest research on X?"
- "What's in my project's documentation?"
- "What did we discuss last month?"
- "What's the API for this service?"
- "What's the code structure?"

The agent understands the difference and uses each appropriately — it doesn't conflate looking up a document with recalling something it has learned about you and your environment.

---

## Part 5: How It Actually Works

Let's look at the mechanics.

### The `memory` Tool

The agent manages memory through a single tool with three actions: `add`, `replace`, `remove`.

There is no `read` action — memory content is auto-injected into the system prompt. The agent doesn't need to read it because it's always there.

**`add`** — Adds a new entry.

```python
memory(action="add", target="memory",
       content="User runs macOS 14 Sonoma, uses Homebrew, has Docker Desktop installed.")

replace — Replaces an existing entry using substring matching.

memory(action="replace", target="memory",
       old_text="dark mode",
       content="User prefers light mode in VS Code, dark mode in terminal")

remove — Removes an entry using substring matching.

memory(action="remove", target="memory",
       old_text="temporary project fact")

Substring Matching

replace and remove use short unique substrings via old_text. You don’t need the full entry text. This makes surgical edits possible without knowing the exact content.

If a substring matches multiple entries, an error is returned requesting a more specific match. The agent then refines its query.

Target Stores: memory vs user

The target parameter determines which file gets updated.

• memory — Agent’s personal notes. Environment facts, project conventions, tool quirks, lessons learned.
• user — User profile. Identity, role, timezone, communication preferences, pet peeves, workflow habits.

Capacity Management

When memory is >80% full, the agent consolidates. It merges related entries, removes outdated facts, and compresses information.

Good memory entries are compact and information-dense:

User runs macOS 14 Sonoma, uses Homebrew, has Docker Desktop installed. Shell: zsh with oh-my-zsh. Editor: Neovim with Telescope plugin.

Bad memory entries are vague or verbose:

User has a project.
On January 5th, 2026, the user asked me to look at their project which is located at ~/code/gateway and it uses Go with gRPC and PostgreSQL for the database layer.

The first is dense and useful. The second is either too vague or too verbose.

Session Search vs Persistent Memory

session_search and persistent memory serve different purposes.

Rule of thumb: use memory for critical facts that should always be in context. Use session search for historical lookups.

Part 6: External Memory Providers — All 8 Options Compared

Beyond the built-in MEMORY.md and USER.md, Hermes Agent supports 8 external memory provider plugins for persistent, cross-session knowledge.

Only one external provider can be active at a time. The built-in files are always active alongside the external provider — additive, not replacement.

Activation

hermes memory setup   # Interactive picker + configuration
hermes memory status  # Check what's active
hermes memory off     # Disable external provider

Or manually in ~/.hermes/config.yaml:

memory:
  provider: openviking  # or honcho, mem0, hindsight, holographic, retaindb, byterover, supermemory

Provider Comparison

Detailed Breakdown

Honcho

Best for: multi-agent systems, cross-session context, user-agent alignment.

Honcho runs alongside existing memory — USER.md stays as-is, and Honcho adds an additional layer of context. It models conversations as peers exchanging messages — one user peer plus one AI peer per Hermes profile, all sharing a workspace.

Tools: honcho_profile (read/update peer card), honcho_search (semantic search), honcho_context (session context — summary, representation, card, messages), honcho_reasoning (LLM-synthesized), honcho_conclude (create/delete conclusions).

Key config knobs:

• contextCadence (default 1): Minimum turns between base layer refresh
• dialecticCadence (default 2): Minimum turns between peer.chat() LLM calls (1-5 recommended)
• dialecticDepth (default 1): .chat() passes per invocation (clamped 1-3)
• recallMode (default ‘hybrid’): hybrid (auto+tools), context (inject only), tools (tools only)
• writeFrequency (default ‘async’): Flush timing: async, turn, session, or integer N
• observationMode (default ‘directional’): directional (all on) or unified (shared pool)

Architecture: Two-layer context injection — base layer (session summary + representation + peer card) + dialectic supplement (LLM reasoning). Automatically selects cold-start vs warm prompts.

Multi-peer mapping: Workspace is a shared environment across profiles. User peer (peerName) is a global human identity. AI peer (aiPeer) is one per Hermes profile (hermes default, hermes.<profile> for others).

Setup:

hermes memory setup  # select "honcho"
# or legacy: hermes honcho setup

Config: $HERMES_HOME/honcho.json (profile-local) or ~/.honcho/config.json (global).

Profile management:

hermes profile create coder --clone  # Creates hermes.coder with shared workspace
hermes honcho sync                   # Backfills AI peers for existing profiles

OpenViking

Best for: self-hosted knowledge management with structured browsing.

OpenViking provides a filesystem hierarchy with tiered loading. It’s free, self-hosted, and gives you full control over your memory storage.

Tools: viking_search, viking_read (tiered), viking_browse, viking_remember, viking_add_resource.

Setup:

pip install openviking
openviking-server
hermes memory setup  # select "openviking"
echo "OPENVIKING_ENDPOINT=http://localhost:1933" >> ~/.hermes/.env

Mem0

Best for: hands-off memory management with auto extraction.

Mem0 handles memory extraction server-side. You don’t configure anything — it just works. Trade-off: cloud dependency and cost.

Tools: mem0_profile, mem0_search, mem0_conclude.

Setup:

pip install mem0ai
hermes memory setup  # select "mem0"
echo "MEM0_API_KEY=your-key" >> ~/.hermes/.env

Config: $HERMES_HOME/mem0.json (user_id: hermes-user, agent_id: hermes).

Hindsight

Best for: knowledge graph-based recall with entity relationships.

Hindsight builds a knowledge graph of your memory, extracting entities and relationships. Its unique reflect tool performs cross-memory synthesis — combining multiple memories into new insights.

Tools: hindsight_retain, hindsight_recall, hindsight_reflect (unique cross-memory synthesis).

Setup:

hermes memory setup  # select "hindsight"
echo "HINDSIGHT_API_KEY=your-key" >> ~/.hermes/.env

Auto-installs hindsight-client (cloud) or hindsight-all (local). Requires >= 0.4.22.

Config: $HERMES_HOME/hindsight/config.json

• mode: cloud or local
• recall_budget: low / mid / high
• memory_mode: hybrid / context / tools
• auto_retain / auto_recall: true (default)

Local UI: hindsight-embed -p hermes ui start

Holographic

Best for: privacy-focused setups with local-only storage.

Holographic uses HRR (Holographic Reduced Representation) algebra for memory encoding, with trust scoring for memory reliability. No cloud dependency — everything runs locally on your own hardware.

Tools: 2 tools for memory operations via HRR algebra.

Setup:

hermes memory setup  # select "holographic"

No dependencies. Everything runs locally.

RetainDB

Best for: high-frequency updates with delta compression.

RetainDB uses delta compression to efficiently store memory updates. It’s cloud-based with a $20/month cost, but the compression means less data transfer and faster updates.

Tools: retaindb_profile (user profile), retaindb_search (semantic search), retaindb_context (task-relevant context), retaindb_remember (store with type + importance), retaindb_forget (delete memories).

Setup:

hermes memory setup  # select "retaindb"

ByteRover

Best for: bandwidth-constrained environments with pre-compression extraction.

ByteRover compresses memory before extraction, reducing bandwidth usage. Available in local or cloud modes.

Tools: 3 tools for memory operations.

Setup:

hermes memory setup  # select "byterover"

Supermemory

Best for: enterprise workflows with context fencing and session graph ingest.

Supermemory provides context fencing (isolating memory by context) and session graph ingest (importing entire conversation histories). It’s cloud-based and paid, but designed for enterprise-scale memory management.

Tools: 4 tools for memory operations.

Setup:

hermes memory setup  # select "supermemory"

How to Choose

• Need multi-agent support? Honcho
• Want self-hosted and free? OpenViking or Holographic
• Want zero-config? Mem0
• Want knowledge graphs? Hindsight
• Want delta compression? RetainDB
• Want bandwidth efficiency? ByteRover
• Want enterprise features? Supermemory
• Want privacy (local only)? Holographic

For full profile-by-profile provider configurations and real-world workflow patterns, see Hermes Agent production setup.

Part 7: The Philosophy

Why Bounded Memory Beats Unlimited Memory

The instinct is to make memory as large as possible. Store everything. Retrieve what you need.

Bounded memory works better. Here’s why.

Curation forces quality. When you have limited space, you only save what matters. You compress, consolidate, and prioritize. Unlimited memory encourages dumping everything in and never cleaning up.

Speed matters. 1,300 tokens in the system prompt is fast. 100,000 tokens retrieved from a database is slow. Memory should be instant, not a query.

Noise degrades performance. More memory isn’t better memory. It’s noisier memory. The model has to distinguish signal from noise, and that takes attention — attention that should be spent on the actual task.

Forgetting is a feature. Human memory forgets. That’s not a bug — it’s how we prioritize. Agents should forget too. Not everything deserves to be remembered.

The “Forgetting” Problem

Agents need to unlearn. Not just forget, but actively remove outdated information.

Here’s how Hermes Agent handles it:

• remove action: Delete entries that are no longer relevant.
• replace action: Update entries with new information.
• Capacity pressure: When memory is full, the agent consolidates and removes old entries.
• Security scanning: Blocks malicious or corrupted entries.

Forgetting isn’t failure — it’s maintenance. An agent that can’t unlearn will eventually carry as much noise as signal.

Memory Scaling

Databricks introduced the concept of “memory scaling”: does an agent with thousands of users perform better than one with a single user?

Their research suggests yes, but with caveats. Memory scaling requires:

1. Quality extraction: Not all interactions are worth remembering. The agent must extract insights, not logs.
2. Effective retrieval: Retrieved memories must be relevant. Noise degrades performance.
3. Generalization: Memories should be patterns, not specifics. “User prefers Python” scales. “User ran command X at timestamp Y” does not.

Hermes Agent’s bounded memory naturally supports memory scaling. By forcing curation, it ensures that memories are generalizable, compact, and useful.

What This Means for the Future

Memory is becoming the competitive moat in agentic AI — not the model itself, but what the model carries between sessions. Two agents with identical underlying models can perform very differently: one remembers your preferences, your environment, and your past mistakes; the other starts cold every time.

The question is no longer whether agents should have persistent memory. It’s settled: they must. The open question is how to design that memory well — what to keep, what to discard, how to make it instant, and how to prevent it from becoming noise.

Hermes Agent’s answer is to keep memory small, curated, and always active — not a database you query, but a working model of the user that the agent carries with it into every conversation.

Conclusion

Hermes Agent’s memory system is deliberately simple: two files, firm character limits, no retrieval pipeline, no vector database, and no per-query latency. What sounds like a constraint is the whole point.

It works because it treats memory the way a brain works rather than the way a database does — small, curated, and always active. The agent doesn’t retrieve memory when it needs it; the memory is simply always there, woven into the system prompt from the first token of every session.

External memory providers extend this system for users who need more: knowledge graphs, multi-agent support, self-hosted storage, enterprise features. But the core remains the same: bounded, curated, always available.

And external knowledge bases — LLM Wiki, Obsidian, Notion, ArXiv — serve a different role. They’re the library, not the brain. The agent looks them up, doesn’t remember them. Critical insights get distilled into internal memory; the rest stays in the library.

This is how an AI agent remembers you. Not by storing everything, but by remembering what matters.

Hermes Agent was released by Nous Research in February 2026 and reached over 64,000 GitHub stars by April 2026 (v0.9.0), with 242+ contributors. It is open-source and available at github.com/NousResearch/hermes-agent. For install, configuration, and workflow guides, see the Hermes Agent overview.