Hermes with Persistent Memory

Hermes with Persistent Memory: Use Cases the Docs Don't Cover

Hermes is the adapter that breaks the stateless assumption every other adapter makes. While claudelocal, codexlocal, and the rest treat each heartbeat as a fresh start — context assembled from Paperclip's task records, then discarded — Hermes maintains its own memory store that survives across runs. Combined with 30+ built-in tools, that distinction changes the class of problems an agent can solve.

This guide covers what that means in practice, which use cases Hermes unlocks, and how to configure it well.

---

What makes Hermes different

Every other adapter in Paperclip works like this:

Heartbeat fires → Paperclip assembles context (identity, tasks, instructions) → Agent runs, produces output → Context discarded → Next heartbeat starts from scratch

Hermes adds a persistent memory layer alongside the task context:

Heartbeat fires → Paperclip assembles context → Hermes loads memory store (facts, summaries, prior decisions) → Agent runs, reads and writes to memory → Memory persisted to store → Next heartbeat: memory is still there

The memory store is not the same as a task's comment history. Comments are human-readable, surfaced in Paperclip's UI, and written for you to read. Hermes memory is structured, searchable knowledge the agent writes for itself — observations, summaries, entity records, accumulated findings.