Your agent has a memory. But does it have a memory policy?
The difference is critical. A memory is a capability, the agent can store and retrieve information across sessions. A memory policy is a set of rules that govern what gets stored, what gets forgotten, and how long information remains relevant.
Without a policy, memory becomes a junk drawer. Everything goes in, nothing comes out cleanly, and after three months your agent is making decisions based on a mix of current facts, outdated assumptions, and irrelevant noise.
The three memory failures I see most often
Failure 1: The hoarder. This agent stores everything. Every search result, every user preference, every intermediate calculation. After 500 runs, its memory is 50,000 tokens of accumulated context, and the model spends more time parsing memory than doing work. Performance degrades. Costs increase. Relevance decreases.
Failure 2: The amnesiac. This agent stores nothing between sessions. Every run starts from zero. It asks the same clarifying questions, makes the same mistakes, and never learns from corrections. Users get frustrated. "I already told you I prefer the short format."
Failure 3: The false rememberer. This agent stores things it shouldn't. A client's confidential data leaks into memory and surfaces in another client's session. A preliminary result gets stored as a confirmed fact and influences future decisions. An outdated preference overrides a recent correction.
All three failures come from the same root cause: no memory policy.
The framework: four questions for every piece of information
Before your agent stores anything, it should evaluate four criteria:
Question 1: Does this information affect future decisions?
If yes, it's a candidate for memory. User preferences (output format, tone, topics of interest) affect future decisions. Business rules (minimum pricing, forbidden actions) affect future decisions. One-time search results do not. Intermediate calculations do not.
If the information only matters for the current run, it stays in the current context and dies when the run ends.
Question 2: Is this information stable or volatile?
Stable information changes rarely: user identity, business rules, tool configurations, validated preferences. Store these with no expiration.
Volatile information changes frequently: market data, news trends, availability status, sentiment scores. Either don't store these, or store them with a short TTL (time to live) and re-validate before using.
The worst outcome is storing volatile information as if it were stable. An agent that "remembers" a stock price from last week and uses it for today's decision is worse than an agent with no memory at all.
Question 3: Is this information confirmed or preliminary?
Confirmed information has been validated, the user explicitly stated a preference, or a fact was verified through multiple sources. Store this.
Preliminary information is uncertain, a single search result, an unconfirmed assumption, a pattern detected from insufficient data. Do not store this as fact. If you must store it, tag it as "unconfirmed" and require re-validation before use.
The false rememberer failure almost always comes from storing preliminary information without tagging it. Three runs later, the agent treats an unconfirmed assumption as an established fact.
Question 4: Does storing this create a privacy or contamination risk?
Client-specific data should never persist beyond the client engagement. Personal data should follow data minimization principles, store only what's needed, for as long as it's needed.
The legal-tech SOUL.md I wrote about two weeks ago illustrates this perfectly: zero memory for contract content. The agent starts fresh every time. Efficiency cost is real, but the privacy risk of cross-client contamination is eliminated.
Implementing this in Hermes
In Hermes, memory lives in MEMORY.md. But MEMORY.md is not just a storage file, it should contain your memory policy, not just your memories.
A good MEMORY.md structure:
Section 1: Policy rules. What gets stored, what doesn't, how long things last, what requires re-validation.
Section 2: Stable memories. User preferences, business rules, validated configurations. These persist until explicitly changed.
Section 3: Temporary context. Information relevant to the current period (this week's trends, current project context). Tagged with a review date.
Section 4: Blacklist. Categories of information that must never be stored. Client financials, personal identifiers, unconfirmed claims, raw API responses.
The Hermes memory configuration that matters
In Hermes config.yaml, the memory_char_limit defaults to 2,200 characters and user_char_limit to 1,375 characters. These are small. They force you to be selective.
This is a feature, not a limitation. If you could store unlimited memory, you would. And your agent would become the hoarder. The character limit forces prioritization: what is the most important thing for this agent to remember?
The answer should come directly from your MEMORY.md policy, which in turn comes from Miro Frame 05 (Data, Memory & Permissions Map) questions 9-12:
· What should the agent remember?
· What should the agent never remember?
· How long should memories stay relevant?
· How does the agent distinguish permanent from temporary information?
If you can't answer these four questions for your agent, you're not ready to deploy it. Memory without a policy is a liability, not an asset.
The principle
Every memory decision comes down to one question: "Will knowing this make the agent's next decision better?"
If yes, store it with the right classification (stable/volatile, confirmed/preliminary) and the right constraints (expiration, scope, privacy).
If no, let it go. An agent with a sharp, curated memory of 20 relevant facts will outperform an agent with a bloated memory of 2,000 accumulated fragments.
Memory is not about storing everything you know. Memory is about knowing what's worth remembering.
— ORBIRESEARCH