What Kind of Forgetting Breaks Your Workflow? A Framework for Hermes Agent Memory Layers

cobi_bean published a thread on choosing memory layers for AI agents. The core thesis: don't start with the plugin. Start with what kind of forgetting would actually break the workflow.
how to choose the right memory layer for your agent: don't start with the plugin. start with what kind of forgetting would actually break the workflow. -- cobi_bean on X
The thread proposes a taxonomy of memory types, each matched to a specific forgetting cost. The framework maps cleanly onto Hermes Agent's three memory layers: built-in persistent memory, plugin-based memory (Honcho), and skills as procedural memory.
The Memory Taxonomy
cobi_bean's thread organizes memory by what breaks when it's lost. The categories start simple and scale up in complexity:
| Memory Type | What Forgetting Breaks | Hermes Implementation |
|---|---|---|
| Durable facts | Agent forgets who you are, your preferences, project structure | MEMORY.md + USER.md (built-in) |
| Cross-session patterns | Agent can't build a model of your behavior over time | Honcho (plugin, optional) |
| Procedural knowledge | Agent re-discovers workflows from scratch each time | Skills (built-in, ~/.hermes/skills/) |
| Conversation recall | Can't find something discussed weeks ago | Session search (built-in, FTS5) |
Each layer has a different cost profile - both in tokens and in operational complexity. The framework's value is forcing the question: which kind of forgetting actually matters for your use case?
Layer 1: Built-in Persistent Memory
Hermes Agent ships with two memory files that are injected into the system prompt as a frozen snapshot at session start:
| File | Purpose | Char Limit | Est. Tokens |
|---|---|---|---|
| MEMORY.md | Environment facts, conventions, lessons learned | 2,200 | ~800 |
| USER.md | User preferences, communication style, identity | 1,375 | ~500 |
The frozen snapshot pattern is intentional: memory is captured once per session and never changes mid-session. This preserves the LLM's prefix cache - a performance optimization that matters at scale. Changes written during a session persist to disk immediately but appear in the prompt on the next session start.
The memory tool supports three actions: add, replace (via substring matching), and remove. There is no read action - memory content is always visible in the system prompt. When a write would exceed the character limit, the tool returns an error with the current entries listed. The agent must consolidate or remove entries in the same turn before retrying.
A practical example of a good memory entry:
User runs macOS 14 Sonoma, uses Homebrew, has Docker Desktop and Podman.
Shell: zsh with oh-my-zsh. Editor: VS Code with Vim keybindings.
A practical example of what to skip:
User asked about Python. # too vague
The system automatically rejects exact duplicate entries and scans all writes for injection patterns before accepting them - this matters because memory content is injected directly into the system prompt.
Layer 2: Honcho - Cross-Session User Modeling
When the agent needs to build a model of the user across many sessions - tracking behavior patterns, communication shifts, and evolving preferences - that's where Honcho comes in. It is an optional plugin (available via hermes honcho setup) that adds five tools: honcho_profile, honcho_search, honcho_context, honcho_reasoning, and honcho_conclude.
Honcho models conversations as interactions between peers - a user peer and an AI peer. Each Hermes profile gets its own AI peer identity, so different profiles develop independent views of the same user. This is useful when you have separate profiles for coding, writing, and operations work.
The key distinction from built-in memory is that Honcho performs dialectic reasoning - it synthesizes observations about the user rather than just storing raw facts. The honcho_reasoning tool answers natural language questions like "What does this user care about most?" using Honcho's backend LLM. The honcho_search tool retrieves specific past facts as raw excerpts with no synthesis - faster and cheaper for targeted lookups.
The cost tradeoff is real. Honcho injects base context (session summary + user representation + AI peer card) into every turn in hybrid mode. The contextTokens budget caps this injection size, trimming the summary first when the budget is tight. Configuring dialecticCadence to fire every 2-3 turns instead of every turn keeps the backend LLM cost manageable.
Layer 3: Skills as Procedural Memory
Skills are the third memory layer - they encode reusable workflows. When you solve a complex problem (5+ tool calls, tricky errors, a discovered pattern), saving it as a skill means the agent can replay that procedure without re-learning it.
Skills live in ~/.hermes/skills/ as markdown files. Unlike MEMORY.md, which stores facts, skills store instructions: numbered steps, exact commands, pitfalls, and verification steps. They are loaded on-demand via skill_view() rather than injected into every prompt - so they cost tokens only when relevant.
The distinction matters. A memory entry says "Project uses Go 1.22, sqlc for DB queries." A skill says "Here is how to build and deploy this project, step by step, with the exact commands and known pitfalls."
Choosing Your Stack
cobi_bean's framework converges on a straightforward decision tree:
Start with built-in memory. Every Hermes Agent session uses it. The 1,300-token cost is fixed and predictable. For most single-user setups, MEMORY.md + USER.md cover the durable facts that matter.
Add Honcho if you need user modeling across sessions. The use case is behavior patterns - "this user always asks for concise answers on weekdays and detailed explanations on weekends" is a Honcho conclusion, not a memory entry. The token cost per turn scales with context budget and dialectic depth.
Use skills for anything you do more than once. The token cost is zero until the skill is loaded, and the skill's content replaces the trial-and-error cost of re-discovering a workflow.
Use session search for conversation recall. The FTS5 index over ~/.hermes/state.db covers everything ever discussed, with no LLM cost. It is slower than memory (a ~20ms query vs instant injection) but effectively unlimited in capacity.
The framework's real insight is not which tool to use - it's that you should know what you're protecting against before you add complexity. Built-in memory protects against the agent forgetting who you are. Honcho protects against the agent failing to learn your patterns. Skills protect against re-discovering known workflows. Each answers a specific forgetting cost, and the right stack is the one that covers the costs that actually break your workflow.
[^1]: cobi_bean. "How to choose the right memory layer for your agent." X. June 15, 2026.
[^2]: Hermes Agent Documentation. "Persistent Memory." Nous Research.
[^3]: Hermes Agent Documentation. "Honcho Memory Plugin." Honcho.