Expiration, Pruning and Reset Rules

A memory store with no expiration policy is a landfill. The exam expects you to know three forgetting mechanisms and when to use each.

The three mechanisms

| Mechanism | What it does | When to use | | --- | --- | --- | | TTL (time-to-live) | Auto-delete after N seconds/hours/days | Ephemeral task scratch, short-lived caches | | Pruning | Active deletion of low-value records | Long-term stores that grow without bound | | Reset | Explicit user/admin wipe of a scope | Trust, compliance, "forget me" requests |

TTLs run on a clock. Pruning runs on a value heuristic. Reset runs on a user intent. You almost always need all three.

Pruning by multiple signals

Single-signal pruning is dangerous. A robust rule combines:

• Confidence: was the fact stored from a high-trust observation or a guess?
• Recency of access: when was the record last retrieved into a working set?
• Supersession: is there a newer record on the same key?
• Source authority: did the user confirm it, or did the agent infer it?

function shouldPrune(record) {
  return (
    record.confidence < 0.5 &&
    daysSinceAccess(record) > 30 &&
    hasNewerOnSameKey(record)
  );
}

Reset must be real

When the user says "forget that", the agent must:

1. Locate every record matching the request in the right scope.
2. Delete them (not soft-hide).
3. Confirm the action back to the user.
4. Log the deletion in an audit trail (the metadata that you deleted, not the deleted content).

Anything less is a trust violation and, under regimes like GDPR's right to erasure, a legal one.

Quick check

Where this shows up on the exam

Watch for scenarios where the agent "remembers something wrong" or the store gets slow. The correct answer combines a TTL on ephemera, a multi-signal pruner on long-term records, and an explicit reset path for the user.