Chapter 11

Memory and Auto-Learning

In Chapter 3, you saw that memory is one of the core components of a Hermes agent — the part that carries facts, preferences, and context forward across sessions. In Chapter 9, you saw feedback loops in action: when you tell the agent to remember a correction, it stores it in memory and applies it next time. But we have not yet explained what memory actually is, how it differs from skills, and what "auto-learning" really means.

This chapter covers three things: how the built-in memory system works (what gets stored, when it is retrieved, what format it takes), the difference between memory and skills (they are not the same thing, and mixing them up causes problems), and how to keep memory clean and useful over time.

A key point up front: memory is a storage-and-retrieval system. It is not intelligence. The agent stores what you tell it to store, and it retrieves what is relevant when a new session starts. It does not independently become smarter. It does not have perfect recall. It does not improve on its own. "Auto-learning" means the agent follows your instructions to persist information — nothing more, nothing less.

How it works

Built-in memory: and

Every Hermes profile has two built-in memory documents. They are plain text files stored in the profile's data directory, and the agent reads them at the start of each session — before it processes your first message.

MEMORY.md

Stores facts the agent has learned during tasks — findings, observations, and conclusions. The agent writes to this file when you tell it to remember something, or when it decides a fact is worth persisting. Example: "The client's top-performing keywords are in the education consulting niche."

USER.md

Stores information about you — your preferences, your communication style, your identity details, and your recurring decisions. The agent writes to this file when you express a preference or ask it to remember something about yourself. Example: "Always write in a direct, professional tone. Avoid jargon."

Both files are loaded into the agent's context at the beginning of every session — before you type anything. The agent treats their contents as established facts, not suggestions. If USER.md says "always write in a direct tone," the agent writes in a direct tone — it does not ask whether you still want that rule every time.

Because these are plain text files, you can inspect them, edit them, or delete them at any time. There is no database, no hidden storage, and no opaque algorithm deciding what the agent remembers. You control what persists by editing the files directly or by telling the agent what to save.

Recall across sessions

: finding what was said before

MEMORY.md and USER.md store facts and preferences — but they do not capture everything that happened in prior sessions. If you discussed a specific keyword strategy three weeks ago and want the agent to recall the details, that conversation may not be in the memory files. It lives in the session history.

Session search solves this. Hermes indexes all session transcripts using a full-text search engine (FTS5, the same technology used by SQLite). When the agent needs to recall something from a prior session, it runs a search, the results are summarized by the model, and the summary is injected into context. The agent does not dump raw session transcripts into its context window — it extracts the relevant parts.

This matters because the raw conversation from three weeks ago might be hundreds of messages long. Injecting all of it would consume most of the context window and crowd out the current task. Summarization keeps the recall useful without overwhelming the model.

bashVerified
$ hermes search "keyword strategy for education consulting"

Found 3 matching sessions:

1. Session 2026-04-23 (research-specialist)
   Summary: Explored keyword clusters for college
   admissions consulting. Identified 12 long-tail
   keywords with low competition.

2. Session 2026-04-15 (seo-manager)
   Summary: Reviewed keyword list and selected top 5
   for the next content cycle. Discussed content
   angles for each keyword.

3. Session 2026-03-28 (research-specialist)
   Summary: Initial keyword discovery for education
   consulting niche. Found 3 high-volume keywords
   with strong relevance.

The search command lets you find past sessions by keyword. The agent can also trigger searches autonomously when it decides that recalling prior context would help with the current task. In both cases, the result is a summary — not a raw transcript.

Distinction

Memory is not skill — and confusing them causes problems

In Chapter 9, you saw that skills are procedural documents — step-by-step instructions for how to do a specific type of work. Memory is different. Memory stores facts and preferences; skills store procedures. The distinction matters because putting the wrong type of information in the wrong place makes the agent less effective.

Put in memory when

  • It is a fact about the world — "Competitor X ranks #1 for this keyword"
  • It is a preference — "I prefer concise briefs under 500 words"
  • It is an identity detail — "I work in education consulting"
  • It is a recurring decision — "Always exclude competitor brand names from keyword lists"
  • It is a learned observation — "The education consulting niche responds better to listicle formats than to how-to guides"

Put in a skill when

  • It is a procedure — "Search for the core topic, then search for 2-3 long-tail variations, then filter by relevance"
  • It is a step-by-step process — "Read the keyword file, select top keywords, draft a brief with these sections"
  • It is a conditional rule with actions — "If the competition level is high, search for alternative long-tail keywords instead"
  • It is an output contract — "Return results as a structured list with keyword, relevance, competition, and angle fields"

The practical test: if the information answers "what is true?" or "what do I prefer?" — it belongs in memory. If it answers "how do I do this?" — it belongs in a skill. A style rule ("write in a direct tone") is memory because it states a preference. A writing procedure ("draft the brief in this order: title, angle, keywords, word count") is a skill because it defines a process.

Why does the distinction matter? Because skills are loaded when the task matches — the agent does not carry every skill in every session. Memory is loaded every session, regardless of task. If you put a procedure in memory, the agent reads it even when the procedure is irrelevant — wasting context window space. If you put a fact in a skill, the agent might not load it when it needs it — because the task trigger did not match.

A well-designed agent keeps memory lean (only persistent facts and preferences) and skills focused (only task-specific procedures). This keeps the context window efficient and the agent's behavior predictable.

Concrete behavior

: three concrete behaviors, not magic

Hermes describes itself as "the agent that grows with you." That tagline is accurate — but only if you understand what "grows" means in concrete terms. Auto-learning in Hermes consists of three specific, observable behaviors:

1. Saves durable facts to memory

When you tell the agent to remember something — a preference, a fact, a decision — it writes it to MEMORY.md or USER.md. Next session, that information is already in context. You do not have to repeat yourself. The agent stores what you tell it to store; it does not independently decide what is worth remembering.

2. Creates skills from repeated work

When the agent notices that you keep asking for the same type of task — or when a task is complex enough that a procedure would help — it can create a skill document capturing the steps. This is not the agent inventing new capabilities. It is the agent documenting a pattern it has observed, so that next time it follows the documented pattern instead of improvising.

3. Patches skills during use

When you correct the agent on a procedure it followed incorrectly, it can patch the skill document to incorporate your correction. Next time the skill loads, the patched version is used. The agent follows instructions to persist your feedback; it does not improvise improvements on its own.

What auto-learning does not mean:

  • The agent does not independently become smarter over time
  • The agent does not have perfect recall of everything that ever happened in any session
  • The agent does not discover better approaches on its own without your feedback
  • The agent does not improve its reasoning ability — the model is the same model every session

The model inside the agent does not change. What changes is the accumulated context: more memory entries, more skill documents, more corrections incorporated into procedures. The agent "grows" because you teach it — not because it teaches itself. Each session builds on the last because you told it what to keep, not because it figured out what to keep on its own.

Your SEO workflow

Style rules that persist across sessions

In Chapter 10, you expanded your SEO team to four profiles: research specialist, SERP analyst, content writer, and SEO manager. The SEO manager reviews every draft before it goes anywhere. But what does "review" mean? What standards does the manager check against?

The answer is: your style rules, stored in memory. When you tell the SEO manager "always write in a direct, professional tone — no jargon, no filler phrases, and keep briefs under 500 words," the manager saves those rules to USER.md. Every subsequent session, those rules are loaded into context before the first message. The manager applies them consistently without you having to repeat them.

Here is what this looks like in practice:

Session 1 — You set the rules

You tell the SEO manager: "Remember these style rules: direct tone, no jargon, briefs under 500 words, always include internal linking suggestions, and never use filler phrases like 'utilize' when 'use' works." The manager writes these rules to USER.md. They are now part of the profile's permanent context.

Session 2 — The rules are already there

You start a new session and ask the manager to review a draft. The manager does not need you to repeat the style rules — they are already in USER.md, loaded into context. It checks the draft against your rules and flags any violations. The review is consistent with Session 1 because the rules are the same rules, stored in the same place.

Session 5 — You add a rule

After a few rounds, you notice the content writer keeps drafting articles that are too long. You tell the SEO manager: "Also remember: article drafts should be 1,500-2,000 words maximum." The manager adds this rule to USER.md. Next session, the new rule is loaded alongside the existing ones.

Session 10 — The manager applies all rules consistently

By Session 10, the manager's USER.md contains five style rules accumulated over multiple sessions. Every review checks against all five — not because the manager is smarter, but because all five rules are in the context every time. The consistency comes from storage, not intelligence.

This is the compounding value of memory. Not magic — just persistent storage. The SEO manager in Session 10 is not smarter than the one in Session 1. It just has more rules in its context. The model is the same model. The difference is entirely in the accumulated memory.

The same pattern applies to the research specialist. In Chapter 9, you saw how the specialist's keyword research skill defines a procedure. In memory, the specialist stores which sources work best for your niche, which keywords tend to perform well, and which filters you prefer. The skill says how to research; the memory says what you have learned about research in your specific context. The combination is more effective than either one alone.

markdownVerified
# USER.md — SEO manager profile

## Style rules
- Direct, professional tone
- No jargon or filler phrases
- Briefs under 500 words
- Always include internal linking suggestions
- Never use filler phrases ("utilize" when "use" works, "in order to" when "to" works)
- Article drafts: 1,500-2,000 words maximum
- Always check keyword file before drafting

## Content preferences
- Prefer listicle format for competitive keywords
- How-to format for procedural topics
- Include at least 3 internal links per article
- Headings use sentence case, not title case

This is a simplified example of what USER.md looks like for the SEO manager profile. Plain text, editable by you or the agent, loaded every session. No database, no hidden state — just a file that persists.

Beyond built-in

External memory providers: when you need more than files

The built-in memory system — plain text files loaded into context — is enough for most starting setups. But as your agent accumulates months of context, finding the right piece of memory becomes harder. USER.md grows. MEMORY.md grows. Session history grows. And the agent has to load all of it every time, even when most of it is not relevant to the current task.

External memory providers address this by adding semantic search and richer recall capabilities. Instead of loading the entire memory file into context, the provider searches for the relevant parts and injects only those. This keeps the context window focused even when the total memory store is large.

Hermes supports several external providers — Honcho, Mem0, and others — but only one external provider can be active at a time. You configure which provider to use through the Hermes configuration file. The built-in system is always active; the external provider runs alongside it.

Maintenance

Memory hygiene: keeping memory clean and useful

Memory that grows without maintenance becomes noise. If you never review what the agent has stored, you end up with outdated facts, contradictory rules, and a memory file so long that it consumes valuable context window space. Memory hygiene is the practice of keeping memory accurate, relevant, and compact.

Review memory periodically

Open MEMORY.md and USER.md for each profile and read what is stored. If a fact is outdated — a keyword that no longer ranks, a competitor that has moved — delete it or update it. If a preference has changed, replace the old rule with the new one. A monthly review is a good starting cadence.

Delete one-time instructions

If you told the agent to remember something for a single task ("remember to check the meta description on page X"), that instruction should not persist. Delete task-specific instructions that have been completed. Memory is for durable knowledge, not for to-do items.

Resolve contradictions

If USER.md says "write in a casual tone" and also says "write in a professional tone," the model has to guess which one applies. Contradictions are worse than missing rules. When you change a preference, remove the old rule — do not just add the new one alongside it.

Keep memory compact

Every line in MEMORY.md and USER.md competes for context window space. If the memory file grows to 2,000 words, that is 2,000 words of context the agent carries every session — whether it is relevant or not. Be selective about what persists. When in doubt, delete. The session search system can always find past details if you need them later.

What should never be saved in memory:

  • API keys, passwords, or secrets — these belong in .env files, not in memory documents
  • Raw conversation logs — session history already stores these; duplicating them in memory wastes context space
  • Task progress — "I am working on task #4" is a session state, not a durable fact
  • Information about other users — memory is per-profile and per-user; do not store details that belong to a different context
  • Speculative or unverified claims — memory should contain confirmed facts, not hypotheses

The rule of thumb: memory should contain things that would still be true and still be useful three months from now. If a piece of information is only relevant for the current task, it belongs in the session conversation — not in memory. If it is a secret, it belongs in the environment configuration — not in a text file.

Takeaway

Memory across your four-agent team

Here is how memory fits into the four-agent SEO team you built in Chapter 10:

Research specialist

Memory: which sources work best for your niche, which filters you prefer, and which keyword patterns have performed well. Skill: the keyword research procedure from Chapter 9. Memory tells the specialist what you have learned; the skill tells it how to research.

SERP analyst

Memory: which competitors consistently rank for your target keywords, which content formats rank well in your niche, and which SERP features (featured snippets, PAA boxes) appear most often. Skill: the SERP analysis procedure. Memory provides accumulated competitive knowledge; the skill provides the analysis method.

Content writer

Memory: your brand voice rules, word count preferences, and structural patterns (do you prefer listicles or long-form?). Skill: the content drafting procedure. Memory carries your style; the skill carries the writing process.

SEO manager

Memory: your comprehensive style rules, publishing standards, approval criteria, and all prior review decisions. Skill: the content brief and review procedures. Memory is the filing cabinet of your judgment; the skill is the checklist the manager follows when applying that judgment.

Each profile has its own memory — isolated from the others. The research specialist does not see the SEO manager's style rules. The content writer does not see the SERP analyst's competitive data. This isolation keeps each agent focused on the facts relevant to its own role. If you want to share a rule across all profiles, you add it to each profile's memory separately — or you put it in a shared project context file in the working directory.

Memory is the mechanism that makes your agent team compound over time. The procedures in Chapter 9 define how each agent works. The coordination in Chapter 10 defines how the team works together. Memory defines what each agent carries forward from session to session. Together, these three layers — procedures, coordination, and accumulated knowledge — are what make an agent team effective. Not the model. Not the tools. The accumulated context.

Your research specialist keeps returning keywords that are too competitive for your niche. You tell it to add a filter rule, and it patches the keyword research skill. But the same problem keeps recurring — the agent sometimes ignores the filter. Where else could you store this rule to make it harder to ignore? Why would that location help?