Skip to main content

​
Overview

Agents need two kinds of memory, and Herm handles both per customer:
KindScopeWhat it holdsManaged by
Session contextOne threadConversation history, tool results, intermediate stateHermes, automatically — including compaction. See Sessions
Observational memoryThe customerPreferences, project facts, corrections, conventionsThe agent, autonomously — plus your product via the Memory API
With memory enabled (the default), observational memory is written without your involvement — the customer says “always end videos with our logo sting” once, and every future run knows. Memory is scoped to the deployment, so one customer’s preferences never influence another customer’s agent.

​
How the agent accesses memory

Memory lives as files in the agent’s workspace, not as an opaque blob in someone else’s system. The agent reads and writes it with its standard file tools, and its memory activity appears on the SSE stream as ordinary tool_call / tool_result events. You can read it, audit it, and build on it — months of accumulated context is some of the most valuable data your product generates, and it stays in a format you control.

​
Seed memory at onboarding

New deployments start with empty memory. Seed durable context so the agent starts informed instead of learning everything from scratch: 
await herm.memories.create("dep_7xK9s2", {
  content:
    "Acme's brand voice is playful but never sarcastic. Primary color #7C3AED.",
});

​
View and edit memories

The Memory API gives your product full CRUD over what the agent knows: 
// Render a "what your agent knows" screen
const { data } = await herm.memories.list("dep_7xK9s2");

// Correct a stale fact
await herm.memories.update("dep_7xK9s2", "mem_2dF8h1", {
  content: "End videos with the new Acme logo sting (v2, March 2026).",
});

// Honor a data-deletion request
await herm.memories.delete("dep_7xK9s2", "mem_2dF8h1");
Each memory carries a source — agent for observations the agent recorded itself, api for ones you created — so your UI can distinguish learned context from configured context. A deleted memory isn’t re-learned unless the customer repeats it.

​
Dreaming

Enable dreaming in the deployment’s features for idle-time self-learning: between sessions, the agent consolidates what it learned — sharpening how it applies your skills, pruning stale notes, and preparing for recurring work — so tomorrow’s runs start smarter than today’s.

​
Best practices for memory management

  • Seed sparingly, let the agent learn the rest. A handful of durable facts (brand voice, key constraints) beats a wall of text the agent has to wade through.
  • Surface memory in your product. A visible “what your agent knows” screen builds trust and catches stale facts early — customers correct what they can see.
  • Prune on correction, not on schedule. When a customer changes direction, update or delete the affected memories rather than letting contradictions accumulate.
  • Use deletion for data requests. memories.delete is the compliance path for right-to-be-forgotten requests, scoped per customer by construction.

​
Resetting

Starting a new thread clears conversation history but keeps memory. To fully reset a customer’s agent, delete the deployment and create a fresh one.