How OMEGA Decides
What to Remember
Every memory system eventually confronts the same problem: you cannot keep everything forever, and you cannot throw things away at random. The naive solutions are flat storage (keep all memories with equal weight) or time-based pruning (delete anything older than N days). Both fail in practice. Flat storage turns into noise. Time-based pruning discards things that still matter. OMEGA takes a third path: importance-weighted exponential decay, where the rate at which a memory fades depends on how critical it is.
The Problem with Flat Memory
Consider what a coding agent accumulates over weeks of active sessions: hard constraints about which APIs to never call, a preference for a particular code style, a lesson learned from a failed deployment, a summary of what was discussed in last Tuesday's session, and a note that the user mentioned preferring dark mode.
These are not equivalent. "Never call the payment API without an idempotency key" is safety-critical. It must survive for months. "Discussed the roadmap for Q2" is useful context for a few days, then becomes noise. If both are stored with the same weight and neither is ever removed, the memory store fills with an undifferentiated pile of facts. Retrieval degrades because the signal is buried in old, low-value summaries.
Flat storage also fails for a subtler reason: retrieval quality depends on discrimination. When every memory has the same weight, the system cannot prefer a recent critical constraint over a month-old session note. Semantic similarity is the only signal. Importance-weighted decay adds a second dimension: recency and criticality both shape what surfaces.
The Science: FadeMem and Cognitive Decay Curves
Human memory does not decay uniformly. The Ebbinghaus forgetting curve, documented in the 1880s and replicated many times since, shows exponential decay with a crucial modifier: emotional salience, repetition, and relevance all slow the decay rate. You forget a stranger's name in days; you remember your first day at a job for decades.
The FadeMem paper (arXiv:2601.18642) proposed importing this principle into LLM memory systems. Rather than a single global decay rate, each memory carries an importance score that modulates how quickly it fades. High-importance memories decay slowly. Low-importance ones decay at the baseline rate or faster. The result is a memory store that behaves more like biological memory: important things stick, routine details fade.
FadeMem also introduced access-aware decay: retrieval itself strengthens a memory, resetting its effective age. If the system keeps surfacing a memory in response to queries, that is evidence it is still relevant. Retrieval is a signal. OMEGA implements both mechanisms.
OMEGA's Implementation
OMEGA's decay system operates on three layers: a per-type importance default, a content marker boost, and a retrieval strengthening mechanism. Here is each layer in detail.
Layer 1: Type-Based Importance Defaults
Every memory type in OMEGA has a default importance score between 0.0 and 1.0. These defaults encode engineering judgment about the category-level criticality of different memory types:
| Memory Type | Default Importance | Rationale |
|---|---|---|
constraints | 1.0 | Hard rules. Must never be forgotten. |
user_preferences | 1.0 | Persistent behavioral directives. |
error_patterns | 0.8 | Failure modes to avoid repeating. |
lessons | 0.7 | Learned behavior, still important. |
decisions | 0.7 | Architectural choices with lasting impact. |
session_summaries | 0.3 | Useful short-term, fades quickly. |
These defaults are not arbitrary. Constraints and user preferences represent directives that the user explicitly communicated. An agent that forgets "never use em dashes in copy" after a week is useless. Session summaries, on the other hand, are operational context: helpful for continuity but not critical once the task is complete.
Layer 2: Content Marker Boosting
The type-based default is a starting point. OMEGA then scans the content of each memory for a set of criticality markers and boosts importance accordingly. Each marker adds +0.1 to the importance score, up to a maximum of 1.0:
CRITICALITY_MARKERS = [
"critical", # +0.1
"never", # +0.1
"always", # +0.1
"must", # +0.1
"mandatory", # +0.1
"security", # +0.1
]
# Example: a memory containing "never" and "security" receives +0.2
# A session summary (default 0.3) with "critical" in the text → 0.4
# A constraint (default 1.0) with any marker → stays at 1.0 (capped)This is a lightweight signal, but it catches the most common patterns in practice. When a user writes "NEVER call the payment API without an idempotency key" or "this is a mandatory security requirement," the memory is automatically elevated. No manual tagging required.
Positive feedback also boosts importance. When an agent receives confirmation that a memory was useful, each feedback point adds +0.05 to the importance score. This creates a reinforcement loop: memories that get acted on and validated accumulate importance over time.
Layer 3: The Decay Formula
Once importance is computed, it feeds directly into the decay rate. Standard exponential decay uses a fixed lambda:
factor = exp(-lambda * days)
OMEGA modifies lambda based on importance. The effective lambda is:
lambda_eff = lambda * (1 - importance * 0.8) factor = max(floor, exp(-lambda_eff * days))
Let's work through the extremes. For a constraint with importance 1.0:
lambda_eff = lambda * (1 - 1.0 * 0.8)
= lambda * 0.2
# A constraint decays at 20% of the base rate.
# With a base lambda of 0.01 (per day), effective lambda = 0.002.
# After 365 days: exp(-0.002 * 365) ≈ 0.48
# After 1 year, a constraint retains ~48% of its weight.For a session summary with importance 0.3:
lambda_eff = lambda * (1 - 0.3 * 0.8)
= lambda * 0.76
# A session summary decays at 76% of the base rate.
# With base lambda = 0.01, effective lambda = 0.0076.
# After 30 days: exp(-0.0076 * 30) ≈ 0.80
# After 90 days: exp(-0.0076 * 90) ≈ 0.51
# After 180 days: exp(-0.0076 * 180) ≈ 0.26The floor parameter prevents any non-permanent memory from decaying to zero abruptly. For high-priority memories (importance score of 0.7 or higher, corresponding to a raw store priority of 4 or above), the decay floor is set to 0.7. This means the memory never drops below 70% of its original weight, no matter how old it gets. It remains in the pool for retrieval; it just becomes less dominant relative to newer memories.
Access-Aware Decay: Retrieval Strengthens Memory
The final mechanism is access-aware decay. When OMEGA retrieves a memory in response to a query, it records the access timestamp. The decay calculation uses the time since last access rather than the time since creation. A memory that was created six months ago but retrieved yesterday has an effective age of one day.
This mirrors the biological mechanism: rehearsal resets the forgetting curve. In practice, it means that memories the agent actively uses stay alive without any manual curation. Memories that are never queried fade naturally, even if they were once high-priority.
Permanent memories bypass the entire decay system. They are assigned an importance of 1.0 by definition, and the decay factor is hardcoded to 1.0 regardless of elapsed time or access patterns. Use permanent memories for immutable facts: API endpoints verified from source files, architectural invariants, security requirements that must never be forgotten.
What This Looks Like in Practice
Abstract math is useful; concrete examples are better. Here are four memory events and how the decay system handles each.
How Decay Improves Retrieval Quality
The decay system is not primarily about storage management. Modern hardware can hold millions of vector embeddings. The reason to decay memories is retrieval quality, not space.
When OMEGA ranks results for a query, it combines semantic similarity with a recency and importance weight. A memory that is semantically relevant but old and low-importance gets ranked lower than a recent, high-importance memory with similar semantic content. Without decay, the ranking is dominated by semantic similarity alone, and old session summaries can outrank current constraints simply because they were worded similarly to the query.
The effect compounds over time. An agent that has been running for six months accumulates hundreds of session summaries. With flat storage, those summaries become an ever-growing mass of low-signal text that competes with high-value memories at retrieval time. With importance-weighted decay, the summaries fade to the background while constraints and error patterns stay prominent.
| Property | Flat Storage | Importance-Weighted Decay |
|---|---|---|
| Old session summaries | Full weight, compete at retrieval | Faded to background over weeks |
| Critical constraints | Same weight as summaries | Near-permanent, always prominent |
| Retrieval ranking | Semantic similarity only | Similarity x recency x importance |
| Storage growth | Linear, unbounded | Self-pruning via decay threshold |
| User correction feedback | Not modeled | +0.05 per positive feedback point |
| Frequently retrieved memories | Not modeled | Age resets on each retrieval |
The 95.4% score on LongMemEval is partly attributable to this ranking behavior. LongMemEval tests whether a system can retrieve the right memory across sessions that span hundreds of turns. Many competing systems fail because their retrieval is dominated by recent or verbose memories that are semantically adjacent to the query but not the actual answer. OMEGA's importance weighting keeps the actual answer prominent even as the session count grows.
Using the System: What Callers Need to Know
If you are using OMEGA as an MCP server, the decay system operates automatically. You do not configure it per-memory. But understanding it helps you write better memory content and choose the right memory type.
# Storing a constraint — maximum importance, near-permanent
omega_store(
content="Never commit API keys to version control. Mandatory security rule.",
type="constraint"
# importance defaults to 1.0, boosted further by "never" and "mandatory"
# floor set at 0.7, effective decay rate 0.2x base
)
# Storing a lesson — high importance, slow decay
omega_store(
content="Always run pytest -x before committing. Learned after a broken CI.",
type="lesson"
# importance 0.7 + 0.1 ("always") = 0.8
# floor at 0.7 for priority >= 4
)
# Storing a session summary — low importance, natural fade
omega_store(
content="Discussed Q2 roadmap. Decided to prioritize the embeddings rewrite.",
type="session_summary"
# importance 0.3, no floor, fades over weeks
)Three practical implications:
Frequently Asked Questions
Does OMEGA actually delete decayed memories?
No. Decay reduces the weight of a memory in retrieval ranking, not its existence in storage. A memory at 0.1 weight is still retrievable; it just ranks far below higher-weight memories for the same query. OMEGA only removes memories that fall below a configurable pruning threshold and have no linked memories depending on them.
Can I override the importance for a specific memory?
Yes. When storing via omega_store(), you can pass an explicit importance value in the metadata. This overrides both the type default and any content marker boosting. Use this when you know a memory's criticality cannot be inferred from type or content alone.
How does retrieval strengthening interact with the decay floor?
They are independent mechanisms. The decay floor sets a minimum weight regardless of elapsed time. Retrieval strengthening resets the effective age of the memory, restarting the decay curve from the access point. A memory at the floor that is retrieved will climb back above the floor as its effective age resets.
What is the base lambda value OMEGA uses?
The base decay rate is calibrated to the expected session cadence. At the default setting, a session summary with no retrieval reaches roughly 50% weight in about 90 days. Constraints at the same setting take over 3 years to reach 50% weight, and the floor prevents them from going below 70%. The exact value is configurable per deployment.
How is this different from what Mem0 or Zep do?
Most competing systems use recency alone as a proxy for relevance, or they keep everything and rely on vector similarity to do the work. Neither approach models importance. A critical constraint that was stored a year ago gets treated the same as a routine note stored last week. OMEGA's importance-weighted system means the constraint retains its prominence regardless of age.
Related reading
OMEGA is free, local-first, and Apache 2.0 licensed.