---
title: "Designing a forgetting policy for AI agents"
description: "A forgetting policy decides what an AI agent forgets, and how: supersession, decay or eviction, retention expiry, or erasure, chosen per data type."
canonical: https://past.dev/guides/forgetting-policy
last-updated: 2026-09-02
---
# Designing a forgetting policy for AI agents

Source: https://past.dev/guides/forgetting-policy

A forgetting policy is the set of rules that decides what an AI agent keeps, demotes, expires and erases, and what it never stores at all. Unlimited memory accumulates stale personalization, privacy exposure, retrieval noise and contradictions. A workable policy uses four distinct mechanisms: supersession closes an old value but keeps it, decay demotes what goes unused, retention expiry removes data after a set horizon, and erasure removes what a deleted source supported. Each mechanism answers a different obligation, so a policy assigns one per data type.

## Why unlimited remembering is a liability

An agent that keeps everything degrades in four independent ways, and each cost grows with the size of the store.

- **Stale personalization.** A user mentioned in January 2025 that they were preparing a move to Berlin. Eighteen months later the agent still frames answers around a relocation that ended long ago. Situations expire; a store without forgetting keeps acting on them.
- **Privacy exposure.** Every stored record enlarges the surface for access requests, breaches and legal discovery. Data kept without a purpose adds risk while adding no capability.
- **Retrieval quality.** Every stored fact competes for a place in a bounded context. Stale candidates crowd out relevant ones; [context rot](/glossary/context-rot) names the resulting degradation.
- **Contradiction accumulation.** The longer old values sit unsuperseded, the more same-subject disagreements the store contains. [Contradictory facts](/guides/contradictory-facts) covers detection and resolution.

The fix is a forgetting policy: a written set of rules, per data type, for what is kept, demoted, expired, erased, and never stored.

## Four mechanisms that forget differently

Forgetting is four distinct operations with four distinct triggers. A policy that only says 'delete after a while' cannot express the differences between them.

| Mechanism | Trigger | What happens | History kept |
| --- | --- | --- | --- |
| [Supersession](/glossary/fact-supersession) | A newer value arrives for the same fact | The old value's validity window closes and the fact stays stored | Yes, with dates |
| Eviction and [decay](/glossary/memory-decay) | Low relevance or long disuse | The item is demoted in ranking or dropped from recall candidates | Configurable |
| Retention expiry | A time horizon set per data type | The record is removed when its horizon passes, see [AI data retention](/guides/ai-data-retention) | No |
| Erasure | An obligation, such as a deletion request | The source is removed along with derived support only it provided, see [GDPR memory deletion](/guides/gdpr-memory-deletion) | A dated tombstone without content |

One axis separates them: supersession preserves history while the other three destroy some of it. Superseding when the obligation was erasure leaves data that must be gone. Erasing when the requirement was supersession destroys history that later questions need.

Memory eviction tuning also affects answer quality. Demote too aggressively and the evidence behind rare but important questions disappears before it is asked for. Long-horizon recall under eviction pressure is part of what public memory benchmarks measure; the [benchmark methodology](/benchmarks/methodology) page describes the test setups.

## What must never be forgotten silently

Some classes of records are exempt from every automatic mechanism and may only leave the store through an explicit, logged action:

- **Facts under an audit obligation.** Decisions the agent acted on, and the evidence behind them, may need to be reconstructed months later. An [audit trail](/guides/ai-audit-trail) requirement overrides relevance decay: an item may drop out of ranking but must remain reconstructable until the obligation ends.
- **Records under a keep obligation.** Some data must be retained for a fixed period under bookkeeping or [record-keeping duties](/guides/eu-ai-act-record-keeping). Eviction and decay must exclude these classes entirely.
- **The record of forgetting itself.** Erasure should leave a dated tombstone stating that a source was removed, when, and on whose authority, while retaining none of the content. Silent erasure makes the store's own history unverifiable.

## What should never be stored at all

The cheapest deletion is the write that never happens. A forgetting policy therefore starts at ingestion, with the classes of data the application excludes before storage:

- **Secrets and credentials.** Passwords, API keys and tokens that show up in pasted logs and screenshots.
- **Payment and government identifiers.** Card numbers and national identification numbers rarely improve an answer and concentrate breach impact.
- **Special categories the product has no feature for.** Health details inside a sales tool, for example. Data no feature reads is exposure without function.
- **Anything the user asked to keep off the record.** An explicit do-not-remember instruction is an ingestion filter rather than a later deletion request.

Exclusion is the application's decision. A memory layer structures, dates and deletes what arrives; choosing what may arrive at all belongs to the caller.

## A forgetting policy worksheet

Five steps produce a policy an engineer can implement and a reviewer can check:

1. **Classify what you store.** Typical types: preferences, identity facts, operational events, message content, sensitive categories. Every following decision is made per type.
2. **Set a horizon per type.** Preferences might refresh on every contact and expire after a year of silence; operational events might keep event-time history for seven years. Write each horizon down; 'indefinite' is a decision and gets written down too.
3. **Choose supersede or delete per type.** Values that change over time get supersession, which keeps history. Data under erasure obligations gets deletion that also removes derived support.
4. **Document who can trigger erasure.** Name the request paths: the user exercising [GDPR Article 17](https://gdpr-info.eu/art-17-gdpr/), a data protection contact, a contract ending. State how long fulfillment takes and what confirmation is issued.
5. **Test that erasure works.** Delete a test source, then ask every question it used to answer. Whatever only that source supported must no longer be returned. Automate the check and run it on each release.

> **Scope**
>
> A forgetting policy governs the memory layer. Copies of the same data in logs, analytics events and model training sets sit outside it and need their own retention decisions.

## Forgetting a source with past.dev

past.dev models erasure at the source level. DELETE /api/v1/ingest/{ingestionId} forgets one ingested source and erases what only that source supported, while facts that other sources also support keep their remaining evidence. The endpoint reference is in the [quickstart](/docs/memory-api/quickstart).

## Frequently asked questions

### Should an AI agent forget things over time?

Yes. Unlimited memory accumulates stale preferences, privacy exposure and contradictions, so a deliberate forgetting policy makes the agent more accurate as well as safer. The policy should distinguish superseding, demoting, expiring and erasing.

### What is the difference between deleting a memory and superseding it?

Supersession closes the old value's validity period and keeps it as history, so the agent can still answer what was true before. Deletion removes the data entirely, which is required when an erasure obligation applies.

### How do I make sure deleted data is really gone from an AI agent's memory?

Test it. Delete the source, then ask the questions it used to answer and confirm that nothing only it supported still returns. Derived facts and summaries built from the deleted source have to disappear too.

### What data should an AI agent never store in memory?

Credentials, payment card and government ID numbers, sensitive categories the product has no feature for, and anything the user explicitly asked to keep off the record. Excluding them at ingestion is cheaper and safer than deleting them later.

### How does past.dev forget a source?

Deleting an ingestion removes that source and erases what only it supported, while facts with other supporting sources keep their remaining evidence. This maps an erasure request to a single API call per source.

## Related

- [AI data retention](https://past.dev/guides/ai-data-retention)
- [GDPR memory deletion](https://past.dev/guides/gdpr-memory-deletion)
- [AI audit trail](https://past.dev/guides/ai-audit-trail)
- [Memory decay](https://past.dev/glossary/memory-decay)
- [Fact supersession](https://past.dev/glossary/fact-supersession)