10. Forgetting Strategies — Memory needs a shredder too¶

~17 min read. Good agents do not only remember well. They also forget on purpose.

Built on the ELI5 in 00-eli5.md. The cleanup-bell — the signal to shred, expire, or down-rank old notes — keeps the memory system useful and safe.

1) Why forgetting is not a bug¶

See the office picture.

too many notes kept forever
        │
        ├── noisy retrieval
        ├── stale behaviour
        ├── higher storage cost
        ├── privacy risk
        └── harder deletion requests

People often think memory quality means retaining more. That is wrong.

Quality means retaining the right things for the right duration. The cleanup-bell protects the desk-note. It protects the filing-cabinet.

It protects the address-book too. Without forgetting, memory stores turn into junk drawers. With careless forgetting, valuable continuity disappears.

So what to do? Use explicit forgetting policies. Not silent drift.

2) Common forgetting mechanisms¶

The main tools are straightforward.

A. TTL¶

Each memory expires after a duration. Good for temporary context.

B. Importance scoring¶

High-value items live longer. Low-value items fade sooner.

C. Garbage collection¶

Run periodic cleanup jobs.

Merge duplicates. Delete unreachable or resolved memory.

D. User-driven deletion¶

Respect explicit delete and privacy requests.

E. Compliance retention rules¶

Some categories must expire quickly. Some must never be stored.

memory item
   │
   ├── temporary? ─────────→ short TTL
   ├── high importance? ───→ extend life
   ├── duplicate? ─────────→ merge or delete
   ├── sensitive? ─────────→ stricter retention
   └── user deleted? ──────→ remove now

Simple, no?

The cleanup-bell is really policy plus automation.¶

3) What should fade first¶

Not all memory ages the same way. These usually decay fast:

one-off formatting requests
temporary project names
ephemeral moods
transient tool outputs These often last longer:
durable communication preferences
role and org context
important task outcomes
compliance-related decisions with audit need

Now what is the problem? Many teams use one TTL for everything. That is convenient.

It is also crude. A dinner preference and a security policy should not age alike. A diary-page about last week's failed rollout may matter for months.

A one-turn ask for extra detail may matter for minutes. So forgetting must be typed. The cleanup-bell should ring differently for each store.

4) Worked example: three memories, three lifetimes¶

Memory A: "For this session, explain in detail." Memory B:

"User prefers Python examples." Memory C: "Assistant accidentally exposed a private account id in a draft."

A good policy might say: - A gets session TTL only - B stays in address-book until changed or deleted

C is stored as a sensitive incident with short access scope and strict review See. Different value.

Different risk. Different lifetime. Now add one more rule.

If the user asks to forget B, remove it from the address-book and any derivative stores. That includes caches and vector indexes.

Deletion is not complete until all copies disappear. This is where many systems quietly fail. They delete the row,

but not the embedding or summary cache. The cleanup-bell must ring everywhere.

5) Privacy and product trust¶

Forgetting is also a trust feature.

If users cannot inspect and clear memory, persistent personalization starts to feel creepy. If temporary requests linger,

outputs become oddly sticky. If sensitive events remain searchable, compliance risk grows.

Look. A memory system should answer three questions. What do we store?

Why do we keep it? When do we delete it? If your system cannot answer those clearly,

it is not production-ready. So what to do? Make retention visible.

Make deletion verifiable. Make the cleanup-bell auditable. That is boring.

It is excellent engineering.¶

Where this lives in the wild¶

ChatGPT Memory controls — user rely on explicit review and deletion so durable memory does not feel uncontrollable.
Microsoft 365 Copilot — enterprise admin needs retention and deletion policies aligned with tenant governance rules.
Intercom support AI — support leader should expire low-value ticket context while retaining only approved customer-profile signals.
Healthcare documentation assistants — clinician require strict retention and deletion handling for sensitive patient context.
GitHub enterprise coding assistants — security team need guarantees that temporary secrets or sensitive traces do not persist in memory stores.

Pause and recall¶

Why is forgetting a quality feature, not only a privacy feature?
What are five common forgetting mechanisms?
In the worked example, why do A, B, and C require different lifetimes?

4. Why is deleting the row alone not enough in many memory systems?¶

Interview Q&A¶

Q: Why use typed forgetting policies instead of one global TTL? A: Different memories carry different utility, risk, and legal obligations. One TTL is simple but usually wrong.

Common wrong answer to avoid: "Because some memories are larger" — size is secondary to value, risk, and retention semantics.

Q: Why must deletion propagate to derived stores like embeddings and caches? A: Otherwise the memory can still be retrieved indirectly. True forgetting requires removing all accessible representations.

Common wrong answer to avoid: "Because indexes get inconsistent" — consistency matters, but privacy and correctness are the central reason.

Q: Why can aggressive forgetting hurt retrieval quality? A: Valuable patterns disappear, so the agent repeats mistakes and loses continuity. Forgetting must be selective, not blind.

Common wrong answer to avoid: "Because users like personalization" — the core issue is task quality and repeatability, not only delight.

Q: Why expose retention controls to users and admins? A: Trust improves when memory behaviour is inspectable and adjustable. Governance also becomes enforceable.

Common wrong answer to avoid: "Only to satisfy regulation" — operational trust and debugging also improve.¶

Apply now (5 min)¶

Exercise: List six memory types for one AI product. Assign each a retention rule. Then choose one delete request and write every store that must be updated. Sketch from memory: Draw the cleanup-bell flow from memory item to TTL, importance check, duplicate merge, and deletion propagation.

Bridge. We can now remember and forget as one agent. Next the harder case: what if many agents share memory and step on each other? → 11-shared-memory-multiagent.md