RFC: Add configurable forgetting and reinforcement for human-like long-term memory

[oldnicke]

Summary

Introduce an optional forgetting and reinforcement mechanism for Hindsight's long-term memory.

The goal is to make memory retrieval behave less like a permanent fact database and more like human memory.

• Memories gradually become harder to retrieve when they have not been used.
• Memories that are actually recalled and used can be reinforced.
• Important or protected memories should decay more slowly or not at all.
• Low-value memories may eventually become eligible for reversible archiving.
• The feature must remain configurable and must not significantly increase recall latency or database write load.

An Ebbinghaus-style forgetting curve is one possible implementation:

R(t) = exp(-Δt / S)

Symbol	Meaning
R(t)	The memory's current retrievability.
Δt	The time since the memory was last reinforced.
S	Its stability or strength.

This issue is intended as an RFC. The user-facing behavior matters more than requiring this exact formula.

Motivation

Human-like memory is particularly important for companion and relationship agents.

A companion should not behave like a mechanical database that permanently repeats every fact the user has ever mentioned. The character's memory and the user's own perception of their shared history should remain reasonably aligned.

Examples

• If the user no longer remembers or cares about a minor detail, repeatedly bringing it up can feel unnatural or intrusive.
• If the user repeatedly emphasizes an important preference, relationship, event, or emotional experience, forgetting it quickly can seriously damage trust.
• Frequently used memories should become more stable.
• Older low-value details should become less likely to appear unless the query strongly cues them.
• The system should preserve abstract, consolidated understanding longer than incidental raw details.

This is not limited to companion agents. The same lifecycle is useful for personal assistants, adaptive tutors, game characters, and long-running agents whose memory stores would otherwise grow indefinitely.

Latency is part of the experience. A correct memory that takes too long to retrieve may still be unacceptable in an interactive conversation. The design should avoid adding an LLM call or synchronous database update to every recall.

Current behavior

Hindsight already applies configurable recency decay during recall reranking:

• HINDSIGHT_API_RECENCY_DECAY_FUNCTION
• HINDSIGHT_API_RECENCY_DECAY_LINEAR_WINDOW_DAYS
• HINDSIGHT_API_RECENCY_DECAY_HALFLIFE_DAYS

This mechanism primarily represents how recent the event itself is. It uses the memory's effective occurrence time and applies a small freshness adjustment to the final ranking.

The proposed mechanism represents a different signal:

Signal	Time anchor	Meaning
Existing recency decay	Occurrence/mention time	How recent was the event?
Proposed forgetting curve	Last reinforcement time	How retrievable is the memory now?

For example, a fact may describe an event from ten years ago but have been reconfirmed yesterday. Its event recency should remain low while its retrievability should be high.

Hindsight also supports observation consolidation and memory invalidation, but currently does not model per-memory stability that changes after successful recall or use.

Proposed behavior

1. Retention model

Each memory receives persistent lifecycle state such as:

• importance
• stability_days
• last_reinforced_at
• last_recalled_at
• reinforcement_count
• access_count
• forgetting_exempt
• lifecycle_state

The current retrievability should preferably be calculated at query time rather than periodically written to every memory:

retrievability = exp(-elapsed_days / stability_days)

This avoids continuously updating the entire memory table.

The initial stability may depend on:

• Fact type: world, experience, or observation.
• Explicit importance.
• Observation evidence/proof count.
• A bank-level policy.
• An explicit permanent/protected flag.

The first implementation should use deterministic defaults and should not require another LLM call during retain.

2. Recall integration

Forgetting should be applied after candidate retrieval and semantic reranking, not as an early hard filter.

A possible scoring model is:

base_score = reranker_score × recency_boost × temporal_boost × proof_count_boost
forgetting_signal = score_floor + (1 - score_floor) × retrievability
final_score = base_score × forgetting_boost

The adjustment should initially be conservative so that a highly relevant old memory can still be recovered when strongly cued.

RRF should continue producing candidates normally. Applying a hard forgetting threshold before RRF could make a forgotten memory impossible to recover even when the query provides a precise cue.

Recall traces should optionally expose:

{
  "retrievability": 0.63,
  "stability_days": 45,
  "last_reinforced_at": "2026-07-20T10:00:00Z",
  "importance": 0.8,
  "forgetting_boost": 1.026,
  "lifecycle_state": "active"
}

3. Reinforcement

A memory should not be reinforced merely because it entered the candidate set.

Possible reinforcement sources, from strongest to weakest, include:

1. Explicit user or application reinforcement.
2. Use in a completed Reflect answer.
3. Reconfirmation through a later Retain.
4. An observation receiving additional independent evidence.
5. Inclusion in the final Recall response.

Internal maintenance queries, candidate retrieval, failed Reflect operations, and consolidation searches should not reinforce memories.

Reinforcement should be asynchronous, idempotent, rate-limited, and subject to diminishing returns. For example:

R_before = exp(-Δt / S_old)
spacing_quality = clamp(1 - R_before, minimum_quality, 1)
gain = reinforcement_gain × source_weight × spacing_quality / sqrt(1 + reinforcement_count)
S_new = min(S_old × (1 + gain), max_stability)

This rewards successful recall after a meaningful interval while preventing rapid repeated queries from making a memory effectively permanent.

A cooldown window should ensure that repeated requests in the same session do not repeatedly increase stability.

4. Reflect and consolidated knowledge

Reflect may perform multiple internal searches, so each internal tool call should not immediately reinforce all returned memories.

1. Collect memory IDs used during the Reflect session.
2. Commit reinforcement only after Reflect completes successfully.
3. Prefer memories referenced or consumed by the final answer.
4. Enforce a per-Reflect reinforcement limit.

Observations should have their own stability. When an observation is returned, its entire set of source memories should not automatically be reinforced. Sources should only be reinforced when they are independently returned or actually used.

Mental models can initially keep their existing freshness/staleness behavior. Source-aware mental model reinforcement can be considered separately once reliable provenance is available.

5. Archiving and pruning

Forgetting should not initially mean physical deletion.

A low-retention memory may become eligible for reversible archiving only when:

• It remains below a configured threshold for a grace period.
• It is not marked permanent or protected.
• Its importance is below a protection threshold.
• It is not under legal hold.
• Archiving does not break required observation provenance.

Archived memories should remain available to audit, export, direct lookup, and explicit restoration.

Automatic physical pruning should be a separate feature, disabled by default, with a longer retention period, dry-run support, bounded batches, and audit logging.

Suggested storage design

A separate one-to-one state table may be preferable to frequently updating memory_units or storing system state inside user-controlled metadata:

CREATE TABLE memory_retention_state (
    memory_id UUID PRIMARY KEY,
    bank_id TEXT NOT NULL,
    importance DOUBLE PRECISION NOT NULL,
    stability_days DOUBLE PRECISION NOT NULL,
    last_reinforced_at TIMESTAMPTZ NOT NULL,
    last_recalled_at TIMESTAMPTZ,
    reinforcement_count INTEGER NOT NULL DEFAULT 0,
    access_count BIGINT NOT NULL DEFAULT 0,
    forgetting_exempt BOOLEAN NOT NULL DEFAULT FALSE,
    exemption_reason TEXT,
    lifecycle_state TEXT NOT NULL DEFAULT 'active',
    below_threshold_since TIMESTAMPTZ,
    archived_at TIMESTAMPTZ,
    model_version INTEGER NOT NULL DEFAULT 1,
    created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
    updated_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

A separate idempotent reinforcement-event table could absorb write bursts and allow workers to batch updates by memory ID.

This design must support both PostgreSQL and Oracle and must respect Hindsight's tenant schemas.

Configuration

The feature should be disabled by default and support gradual rollout.

Mode	Behavior
observe	Calculate and trace scores without changing ranking.
rank	Influence reranking and record reinforcement.
filter	Allow threshold filtering.
lifecycle	Enable reversible archiving.

Example deployment configuration:

HINDSIGHT_API_FORGETTING_ENABLED=false
HINDSIGHT_API_FORGETTING_MODE=observe
HINDSIGHT_API_FORGETTING_BASE_STABILITY_DAYS=30
HINDSIGHT_API_FORGETTING_MAX_STABILITY_DAYS=3650
HINDSIGHT_API_FORGETTING_SCORE_ALPHA=0.2
HINDSIGHT_API_FORGETTING_SCORE_FLOOR=0.2
HINDSIGHT_API_FORGETTING_RECALL_THRESHOLD=0.0
HINDSIGHT_API_FORGETTING_REINFORCEMENT_ENABLED=true
HINDSIGHT_API_FORGETTING_REINFORCEMENT_COOLDOWN_HOURS=6
HINDSIGHT_API_FORGETTING_ARCHIVE_ENABLED=false
HINDSIGHT_API_FORGETTING_ARCHIVE_THRESHOLD=0.05
HINDSIGHT_API_FORGETTING_ARCHIVE_GRACE_DAYS=30
HINDSIGHT_API_FORGETTING_AUTO_PRUNE_ENABLED=false

Per-bank overrides would be important because a companion bank, historical archive, customer-support knowledge base, and compliance store need very different behavior.

Suggested precedence:

safe request override > bank configuration > deployment default

Companion-agent example

Assume the user mentions these memories:

1. “My name is Alice.”
2. “My dog Rex died last year.”
3. “I had noodles for lunch today.”
4. “I prefer tea, not coffee,” repeated several times over multiple sessions.

Expected behavior:

Memory	Expected handling
User's name	Protected or assigned very high importance.
Loss of Rex	Emotionally significant and decays slowly.
Today's lunch	Starts with low stability and becomes difficult to recall over time unless it becomes relevant again.
Tea preference	Repeated reinforcement makes it increasingly stable.

• If the user explicitly asks what they ate on that date, the precise query may still recover the low-retention lunch memory.
• The character should not repeatedly surface the lunch detail in unrelated conversations merely because it exists in storage.

Performance constraints

The feature should avoid:

• An LLM call for every retained memory.
• Synchronous updates to every candidate returned by each retrieval arm.
• Periodic full-table retention-score updates.
• Moving archived memories between tables in the initial implementation.

Preferred approach:

• Calculate retrievability only for the merged candidate set.
• Batch-load retention states after RRF.
• Asynchronously insert deduplicated reinforcement events.
• Batch reinforcement updates by memory ID.
• Scan archiving candidates using indexed coarse time cutoffs.
• Keep archived data in place and filter it through lifecycle state.

Suggested initial target: less than 5% increase in Recall p95 latency when ranking is enabled.

Rollout proposal

Phase 0: Observe mode

• Add the curve, state model, trace fields, and metrics.
• Do not modify ranking or write reinforcement.
• Measure the retention distribution and simulated top-k changes.

Phase 1: Conservative reranking

• Apply a small forgetting boost.
• Roll out per bank.
• Keep filtering, archiving, and deletion disabled.

Phase 2: Asynchronous reinforcement

• Add idempotent reinforcement events.
• Reinforce completed Recall and Reflect usage.
• Add cooldowns, source weights, and stability caps.

Phase 3: Filtering and reversible archiving

• Add archive preview and dry-run.
• Introduce threshold filtering and grace-period archiving.
• Add explicit pin, archive, and restore operations.

Phase 4: Optional cold storage or pruning

• Consider only after archive precision has been validated.
• Keep automatic deletion separately controlled and disabled by default.

Acceptance criteria for the initial implementation

• The feature is disabled by default.
• Observe mode does not change result ordering.
• Retrievability is calculated from stability and last reinforcement time.
• No periodic update of every memory is required.
• Existing recency scoring remains semantically separate.
• Recall trace can explain the forgetting score.
• Feature-off behavior and ordering remain unchanged.
• Tests cover time zones, future timestamps, missing state, protected memories, and curve boundaries.
• PostgreSQL and Oracle are both supported.
• Tenant isolation is preserved.
• Recall latency impact is measured.

Open questions

1. Should final Recall response inclusion count as successful use, or should reinforcement require an explicit acknowledgment from the caller?
2. Should a completed Reflect reinforce all retrieved memories or only memories cited by the final answer?
3. Should observations inherit stability from their sources, or maintain fully independent stability?
4. Should archived memories remain eligible for explicit, high-confidence recovery?
5. Should importance initially be deterministic, explicitly provided, or optionally evaluated by an LLM?
6. How should this interact with invalidation and restoration?
7. Should the existing recency boost be reduced when forgetting reranking is enabled to avoid applying two age-related adjustments?
8. What latency and write-QPS budgets should be enforced before enabling reinforcement by default?

Alternatives considered

Increase the existing recency-decay weight

This does not model reinforcement and confuses event recency with memory retrievability.

Periodically update a retention score on every memory

This creates continuous write amplification, stale values between jobs, and expensive multi-tenant scans.

Delete memories immediately below a threshold

This is difficult to calibrate and risks irreversible loss. Reversible archiving is safer.

Reinforce every retrieval candidate

This creates a popularity feedback loop and allows internal searches or repeated requests to make memories effectively permanent.

[oldnicke]

I’ve implemented an initial working prototype based on this proposal:

https://github.com/oldnicke/hindsight/tree/feat/ebbinghaus-forgetting

The implementation is currently split into two commits:

1. Opt-in Ebbinghaus retrievability scoring

   • disabled by default
   • observe and rank modes
   • query-time R = exp(-t / S)
   • conservative integration with the existing recall reranker

2. Persistent reinforcement and lifecycle management

   • retention state and idempotent reinforcement-event tables
   • Retain initialization and lazy initialization for existing memories
   • Recall and Reflect reinforcement
   • cooldown, spacing quality, source weights, and diminishing returns
   • reversible archiving and opt-in physical pruning
   • PostgreSQL and Oracle migrations

Before opening a PR, I’d appreciate maintainer feedback on:

• whether the separate retention state/event-table architecture fits Hindsight;
• whether reinforcement should be triggered by final Recall results and memories explicitly used by Reflect;
• whether you would prefer this as one PR or as a sequence of smaller PRs.

My preference is to submit it incrementally:

1. scoring model, configuration, and observability;
2. persistent retention state and reinforcement;
3. archive/prune lifecycle and management APIs.

The feature remains disabled by default, and automatic pruning requires a separate explicit opt-in.

If this direction is acceptable, I’ll rebase onto the latest main branch, align the implementation with the preferred scope, add the remaining integration/migration coverage, and open the first PR linked to this discussion.

[nicoloboschi]

Hindsight has most of the primitives to build something stacked on it with custom logics.

the forgetting mechanism is very subjective and so far we haven't seen a clear, practical, concrete example of how and what to forget.

recall already has recency decay builtin

[OnourImpram]

On open question 6 — "How should this interact with invalidation and restoration?" — there is a concrete answer, because Hindsight's invalidation is a storage move rather than a flag, and that collides with the proposed retention table.

Invalidation retires a fact by moving its row out of memory_units into invalidated_memory_units. The migration that added that table is explicit that the archive is "cold storage, never a recall surface", and that associations are cascade-deleted "when the live row is removed" — which is why entity_ids and causal_links are snapshotted onto the archive row so revert can restore them.

The prototype branch (oldnicke/hindsight at 680e230) declares retention state against the live table: memory_retention_state.memory_id is the primary key and references memory_units(id) ON DELETE CASCADE, and memory_reinforcement_events.memory_id does the same, in both the Postgres and the Oracle path. Reading the schema rather than running it: invalidating a memory drops its retention state and its idempotent reinforcement-event log, and revert returns the fact with default stability and reinforcement_count = 0. A preference reinforced across a year of sessions, invalidated once and reverted, comes back brand new. Nothing under engine/forgetting/ mentions invalidation or revert, and neither does the branch's diff to memory_engine.py. The RFC body's own SQL declares no FK at all, which trades the cascade for an orphaned retention row pointing at an id no longer in memory_units — same question, different failure.

So, proposed answer to Q6: archiving states something about attention, invalidation states something about truth, Hindsight already stores those separately, and a truth-state transition should carry retention state with it — snapshot it onto the archive row the way entity_ids already is, restore it on revert. That also settles Q4 ("Should archived memories remain eligible for explicit, high-confidence recovery?") with a reason rather than a preference: lifecycle_state = archived asserts nothing about truth, so yes. Worth a clause in §5 too, since the two mechanisms now share the word "archive" with opposite storage semantics — the performance-constraints section says "Keep archived data in place and filter it through lifecycle state.", while invalidated_memory_units moves rows out.

On the concrete-example point raised above — "a clear, practical, concrete example of how and what to forget" — the RFC's own list has one. "I had noodles for lunch today." is true, stays true, and is therefore never invalidatable; and by the RFC's own table the existing recency signal is anchored to occurrence time, so today it is the freshest thing in the bank. The target set is memories that are true, permanent, and not worth surfacing: exactly the gap between the two mechanisms that already exist.

Disclosure: I maintain mneme, which took the opposite decision at this seam — a superseded claim keeps its row, carries valid_from/valid_to plus a supersedes pointer, and the as-of query recomputes which claims are live at a timestamp, so no row moves and no dependent state can cascade away. That is paid for at query time, which is exactly what the row-move buys you. mneme has no reinforcement or decay model at all, so it has nothing useful to say about §3's stability curves.

AI-assistance disclosure: this comment was drafted with Claude Code under my authorization, and every claim it makes about my own project was checked against the repository before posting.

[oldnicke]

This implementation above relies on the Ebbinghaus Forgetting Curve to manage memory across its entire lifecycle. Lately, I have been delving into a critical question: is the human-like memory forgetting mechanism truly an optimal forgetting scheme for agent memory? Should silicon-based entities inherit the inherent limitations of human memory decay?