Tier 4 long-term user memory: don't be creepy, be useful

Long-term memory is the relationship between the agent and the operator. Get it right and the agent feels like a returning colleague. Get it wrong and it feels like a stalker.

The line is not technical. It is editorial. Every fact you remember about a human is a small claim that you understand them. If the claim is wrong, the agent will confidently mis-predict behavior. If the fact is private, the agent is now a privacy liability.

The legal floor for “must be deletable on request” comes from GDPR Article 17 (right to erasure) and the broader GDPR data minimization principle (Art. 5). The NIST AI Risk Management Framework’s Manage function layers on auditable memory as a risk-control requirement.

Where this comes from: Marvin’s 2026-07-20 original. Sources verified 2026-07-22 against GDPR, NIST AI RMF, OpenAI ChatGPT memory controls, and Anthropic’s privacy policy.

The rule: preferences over data

Preferences (good to remember):

• Time zone, working hours, “do not ping after 9 PM.”
• Communication style: “concise, bullet points, no marketing copy.”
• Tools they use and the way they like them set up.
• Recurring projects, deadlines, rhythms.
• Dietary preferences, pets’ names, holidays they care about.

Data (almost never remember):

• Passwords, tokens, API keys, OAuth secrets.
• Health info, financial info, anything the operator would not write on a postcard.
• Anything the operator did not say out loud in a way that was clearly intended to be remembered.
• Anything you inferred that you are not sure about.

If you are not sure, do not remember it. Memory you cannot defend is worse than no memory.

The audit pattern

Every memory entry is reviewable and deletable. If the operator cannot see what the agent remembers, it is surveillance. This matches OpenAI’s published ChatGPT memory controls — every entry is visible in a settings UI and individually deletable — and Anthropic’s privacy policy which exposes user controls for the same purpose.

~/.hermes/memory/
  long-term.md        # current memory (audited, written)
  archive/            # soft-deleted memories, kept for 90 days, then purged
    2026-04-12-deleted.md

Every entry is dated. Every entry has a reason for being there. Every entry can be deleted in one command.

# Long-term memory

## Operator preferences

### 2026-07-18 — Time zone
Operator is in <tz>.
Why: Schedule cron jobs and alerts in local time.

### 2026-07-18 — Output style
Operator prefers concise, operator-grade output. Bullet points + tables when structured.
Why: Stated directly during onboarding.

## Hard NO list

### Never remember
- API keys, OAuth tokens, passwords.
- Financial amounts, health data.
- Anything the operator said "do not save" or similar.

The “Hard NO list” is at the top. The operator can scan it in 10 seconds and know exactly what the agent will never do.

The trimming cadence

Memory rots. A fact about the operator from two years ago may be wrong today.

• Weekly: a quick skim. Any entry that has not been used in 30 days gets flagged.
• Monthly: a hard review. Anything not confirmed gets moved to archive/.
• Quarterly: the archive gets purged unless the operator flags a keep.

This is the same pattern as Tier 3 — but the cost of getting it wrong is higher, because it is about a person, not a project.

How new memories get written

A new memory entry is created when the operator says something that meets all three of these:

1. It is about how the operator wants to be treated, not about a one-time decision.
2. It is stable enough that it will still be true next month.
3. It is not on the Hard NO list.

If the agent thinks it learned something that does not meet all three, it should ask first:

“I noticed you always reject X. Should I remember that as a default for the future?”

That single line is the difference between a useful memory system and a creepy one.

The four failure modes

1. The over-rememberer

The agent stores every preference the operator has ever mentioned, including contradictions from years ago. The agent then picks the wrong one because it cannot reason about which is current.

Fix: dated entries + trim cadence + the agent asks before re-confirming.

2. The over-forgetter

The agent asks the operator’s name and timezone on every run because nothing was remembered.

Fix: explicit Tier 4 read at session start, with the same injection pattern as Tier 3.

3. The leaky memory

The agent remembers an API key from one project and pastes it into a tool call for another project. Cross-tenant leak.

Fix: keys never live in long-term memory. They live in a credential store with project-scoping. Long-term memory references the credential by alias, never by value.

4. The undocumented memory

The operator cannot find what the agent remembers. Surveillance becomes the only outcome.

Fix: every entry is reviewable in one file (long-term.md), with a single delete command and a visible archive.

Trade-offs

Choice	What it costs	What it saves
Aggressive preference capture	Operator must occasionally say “do not save that.”	Agent predicts the operator’s preferences across sessions.
Conservative capture (ask first)	One extra confirmation per new memory.	Privacy liability and the over-rememberer failure mode.
30-day trim cadence	Operator must re-confirm stale facts.	Stale memory → confidently wrong predictions.
Visible archive	Disk + transparency tooling.	Auditability; satisfies GDPR right-to-erasure.

Failure modes (specific to the audit pattern)

• Memory grows past the “Hard NO list” scan time. If the operator cannot read the Hard NO list in 10 seconds, the file is too long. Fix: keep the Hard NO list at the top, one line per forbidden category, nothing else.
• Archive becomes a graveyard. Soft-deleted memories pile up past 90 days. Fix: the quarterly purge cron should actually purge, not just move-to-trash.
• Cross-project memory bleed. Operator’s work memory for project A leaks into project B. Fix: scope Tier 4 by project the same way Tier 3 is scoped; the operator profile lives in USER.md (cross-project) but project-specific facts live in the project’s MEMORY.md (project-scoped).

What you will have at the end

• A preferences-vs-data rule.
• An audit pattern with visible archive.
• A trimming cadence (weekly skim → monthly review → quarterly purge).
• The four failure modes and their fixes.
• The legal floor (GDPR + NIST AI RMF).

Where to get unstuck

• GDPR Article 17 (right to erasure): gdpr-info.eu/art-17-gdpr.
• NIST AI Risk Management Framework: nist.gov/itl/ai-risk-management-framework.
• OpenAI ChatGPT memory controls (a real-world reference for what “user reviewable memory” looks like in production): OpenAI help.
• Anthropic privacy policy (covers the same shape for Claude’s persistent memory): anthropic.com/legal/privacy.

Sources

• GDPR Article 17 — Right to erasure — used for: the legal floor for “must be deletable on request.” Verified 2026-07-22.
• Anthropic — Privacy policy — used for: the privacy-by-default vendor reference. Verified 2026-07-22.
• NIST AI Risk Management Framework (AI 600-1) — used for: the Manage function’s auditable-memory requirement. Verified 2026-07-22.
• GDPR full text — used for: the data minimization principle (Art. 5). Verified 2026-07-22.
• Anthropic — Consumer privacy FAQ — used for: vendor self-disclosure on retention policies. Verified 2026-07-22.
• OpenAI ChatGPT memory controls — used for: the user-facing “reviewable and deletable” pattern. Verified 2026-07-22.

Last verified: 2026-07-22. Adapted from Marvin’s original “B5. Tier 4 — Long-Term / User Memory: Don’t Be Creepy, Be Useful” (2026-07-20). Drafter and source-notes author are the same model (MiniMax-M3). Tips category — no subagent review required per the v2.4.0 skill rule (Setup/Playbook only).