Memory Write Triggers: When the Agent Commits to Memory

Introduction

The agent does not save everything it sees. If it did, persistent memory would fill with noise within an hour. Hermes treats writing to memory as a deliberate act with a small number of triggers, and understanding those triggers lets you predict when memory will update and when it will not.

Key Concepts

• Trigger: A reason the agent decides a fact is worth persisting.
• Proactive write: The agent saves on its own when a fact matches a trigger.
• Explicit write: You tell the agent to remember something ("remember that we use pnpm").
• Skip rule: Categories of information the agent deliberately refuses to save.

Real World Context

A user says "I prefer four-space indentation." That is a stable preference. The agent saves it. Later the same user says "the dev server crashed on port 5435." That is a one-off event. The agent does not save it. Without internalized triggers, the agent would either be too noisy (saving the crash) or too quiet (asking again about indentation).

Deep Dive

Hermes's documented triggers for proactive writes are:

1. Stated preferences and communication style: "I prefer terse answers", "comments only when the why is non-obvious".
2. Stable environment and configuration: OS, shell, primary repo, test command, package manager.
3. Corrections and workarounds: "That command does not work on macOS, use this one instead".
4. Project conventions: "Migrations are generated, never hand-edited".
5. Explicit instructions: "Remember that the dev DB is on port 5435".

And the documented skip rules (the agent will not save):

• Trivial or vague facts ("User has a project").
• Easily re-discoverable information (anything the agent can find by searching the web).
• Raw data dumps, code blocks, or long logs.
• Session-specific temporary paths.
• Content already stored in context files (AGENTS.md, SOUL.md).

The add operation in the memory tool is what implements a write. The agent forms a candidate entry, the entry goes through the security scanner, and if accepted it lands in MEMORY.md or USER.md immediately. Exact duplicates are rejected. If the relevant file is over capacity, the tool returns an error and lists existing entries so the agent can consolidate.

A subtle point: the agent often clusters multiple related facts into a single entry rather than writing four small entries. This is because the character cap rewards density. "Project ~/code/api uses Go 1.22, sqlc, chi router, make test, GitHub Actions CI" is one entry that carries four facts.

Common Pitfalls

1. Expecting the agent to remember everything you say: It will not. If something is important and the agent has not saved it, ask explicitly: "please remember that".
2. Filling memory with debugging artifacts: Asking the agent to remember a stack trace burns capacity for a fact you will not need next month.

Best Practices

1. Confirm critical writes: After telling the agent something important, run /memory (or read ~/.hermes/memories/MEMORY.md) to confirm it landed.
2. Bias toward density: When you ask the agent to remember a fact, give it surrounding context so the entry can hold its weight: "remember that we use pnpm at this project; npm scripts will silently break the lockfile".

Summary

• Hermes writes to memory only for a small set of triggers: stable preferences, environment, corrections, conventions, and explicit requests.
• It refuses to save trivia, large data, session-specific paths, or anything already in context files.
• Writes are immediate to disk but only visible to the model at the next session start.
• Density beats frequency: one packed entry outperforms several thin ones.

User: remember that we use pnpm for this project, not npm. npm scripts break the lockfile silently.

Agent: Saved to MEMORY.md:
  "Project uses pnpm exclusively. npm scripts silently corrupt the lockfile; never run npm install here."

  MEMORY.md is now 47% full (1043 / 2200 chars).