Skip to content

Feature Request: Memory Decay & Salience Pruning in STLTMemory #214

@Harshitmehra-270709

Description

@Harshitmehra-270709

🚀 Feature Request: Memory Decay & Salience Pruning in STLTMemory

📖 Background & Problem Statement

Currently, STLTMemory operates by asking the LLM to summarize and continuously update the long_term_memory string upon consolidation.

While this accurately replaces the string rather than doing naive appending, the long-term memory lacks strict forgetfulness thresholds. Over thousands of simulation steps, the LLM naturally tries to persist historical details. This causes the summary string to grow indefinitely, presenting two critical problems:

  1. Context Window Limitations: Prompting the LLM with an ever-expanding summary string will eventually breach context limits or severely increase latency/API costs.
  2. Behavioral Realism: Real-world entities experience decay curve memory—older or less relevant information is naturally forgotten or compressed. Currently, agents possess perfect lifelong recall.

💡 Proposed Solution

Introduce a Memory Decay Mechanism directly into the STLT architecture.

Key Additions:

  1. Decay/Salience Factor: We propose adding a configurable decay_rate or a token-limit threshold to STLTMemory.
  2. Periodic Re-summarization (Pruning): Instead of only appending to long_term_memory, if the long-term string exceeds a specified token limit/character length, the memory system should trigger a "Pruning/Compression" LLM pass.
  3. Prompt Update:
    Your current long-term memory is too long. Please compress it, retaining only the most critical overarching facts and discarding less salient/older details.
    

🛠 Impact & Value

  • Scalability: Allows simulations to run infinitely without crashing due to LLM context overflow.
  • Cost-Efficiency: Prevents sending massive text accumulations to costly high-tier APIs.
  • Scientific Realism: Brings psychological decay principles into ABM modeling, creating more realistic agent behaviors.

👋 Implementation Plan

I am an active contributor and would love to take ownership of implementing this architecture. I will:

  • Introduce long_term_token_limit configs.
  • Expand st_lt_memory.py to support compression prompting.
  • Write full unit tests verifying the decay threshold behaviors.

Let me know if the maintainers are aligned on this architectural direction, and I will happily open a PR!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions