Not all memory should last forever. A preference you recorded eight months ago may no longer reflect how someone works. A technical decision made last quarter may have been reversed. A session note from Tuesday is probably irrelevant by Friday. Memory that doesn't decay accumulates noise — and noise degrades retrieval, increases storage cost, and makes importance scoring less reliable.
Ebbinghaus described forgetting as a curve: retention drops steeply at first, then levels off. The shape and speed of that curve depends on the type of memory, how often it's accessed, and how meaningful it was when it was formed. Your memory system will have the same dynamics — but only if you design them in deliberately.
Calibration is the work of matching your decay parameters to the actual half-life of different memory types. Get it right and your system automatically surfaces fresh facts and archives stale ones. Get it wrong and you're either forgetting things too fast — forcing unnecessary re-learning — or hoarding everything equally, which is no better than no decay at all.
A developer builds a memory system for a personal AI assistant. The system accumulates facts from every conversation: user preferences, project decisions, technical constraints, session notes, one-off requests. After six months, the memory store has grown to over 4,000 entries. Retrieval is slow. Importance scores are compressed — everything scores between 0.3 and 0.5, making ranking nearly useless. And the AI keeps surfacing obsolete context alongside current facts with equal confidence.
The developer applies decay. All memories decay at the same rate: weight multiplied by 0.95 every 24 hours, with a floor of 0.1. After a few weeks, the problem shifts. Session notes from last week are gone — decayed to the floor before the project they related to was even finished. Meanwhile, a technical constraint recorded two years ago and never accessed since still sits at 0.1, occupying space and occasionally showing up in retrievals.
The problem is not that decay was applied. The problem is that one curve cannot fit all memory types. A session note from Tuesday should decay in days. A core architectural decision should decay over months, if at all. A user preference that gets reinforced frequently should have its decay reset on access. A constraint that hasn't been touched in a year should probably decay faster than something the user references weekly.
One decay rate, applied uniformly, produces a system where the wrong things expire and the wrong things persist. What the developer needed was not a single forgetting curve — but a taxonomy of memory types and a calibrated curve for each.
Decay calibration has four parts: choosing the memory type, selecting the decay function shape, setting the parameters, and defining how reinforcement interacts with decay.
Different memory types have different natural half-lives. Episodic memories — session notes, task logs, conversational context — are time-bound and decay quickly. They're relevant during and immediately after a project phase, then mostly obsolete. Preference memories — working style, format preferences, communication style — change slowly and should decay over months, not days. Access resets the clock.
Semantic memories — factual knowledge, domain concepts, vocabulary — are relatively stable. They may never need to decay unless the domain changes. Procedural memories — how a task is done, which tools are used, step sequences — are stable until a workflow changes, then should drop sharply. A step-decay function (holds, then drops) often fits better than exponential for this type.
Exponential decay — weight × decay_rate per period — is the most common. Weight erodes continuously, mimicking natural forgetting. It's smooth, predictable, and easy to implement. The half-life is controlled by the decay rate: a rate of 0.97 per day gives a half-life of about 23 days; a rate of 0.90 gives about 6.5 days.
Step decay holds the weight constant until a threshold time passes, then drops it sharply — or by a large increment. This fits procedural memories well: a workflow that was used last year is either still valid or completely obsolete, rarely somewhere in between.
Access-reset decay pauses or resets decay entirely on each access. The memory's age resets to zero each time it's retrieved. This is the right model for preference memories: if the user references a preference frequently, it should stay strong regardless of calendar time.
Three parameters define a decay curve: decay rate (how much weight is lost per period), half-life (implied by the rate — how many periods before weight reaches 50%), and floor (the minimum weight below which decay stops). A floor prevents a memory from reaching zero weight — which would make it permanently unretrievable — while still deprioritizing it heavily.
Choosing a floor matters. Too high (0.4) and old memories compete with fresh ones. Too low (0.05) and you're storing data that will never be retrieved. A floor between 0.08 and 0.15 is typically appropriate for memories you want to keep but deprioritize.
When a memory is reinforced — accessed, referenced, or confirmed — its weight increases (Module 5's rule: weight += learning_rate × (1 − weight)). Decay and reinforcement interact. If a memory is reinforced frequently, the net effect of decay is small or negative — the memory stays strong. If a memory is never accessed, decay steadily reduces it toward the floor.
The design question is whether access also resets the decay clock. It usually should for preference memories and semantic facts. For episodic memories, access doesn't necessarily mean the memory is still current — a session note accessed once last month is still old.
NIST's MANAGE function requires that AI operational parameters be documented, monitored, and adjusted when they deviate from expected behavior. Decay rates are operational parameters — they directly affect what the AI knows and doesn't know. Setting them once and never reviewing them is an unmanaged risk. A managed decay curve has defined review triggers: when retrieval quality drops, when the memory store grows unexpectedly fast, or when users report stale facts surfacing.
Calibration should be measurable. Useful metrics: average weight of memories by type (are they distributing as expected?), retrieval age distribution (how old are the facts being surfaced?), floor hit rate (what fraction of memories have decayed to the floor?), and reinforcement frequency by type (which memories are being accessed and which are not?). Track these before and after any decay parameter change.
Before choosing decay parameters, you need to answer three questions for the specific memory tier you're calibrating. Abstract decay rates are meaningless — the right parameters depend entirely on what the memories are and how the system uses them.
Before writing a formula, estimate how long these memories stay relevant in practice. Session notes from a completed project: days. A preference about meeting frequency: months. A core architectural decision the team still follows: potentially indefinitely. Your decay rate should produce a half-life that matches this natural timeline — not a rate chosen for mathematical convenience.
Over-decay means the system forgets too fast — users re-explain things they already told the AI, or the AI contradicts past decisions. Under-decay means the system accumulates stale facts — context windows fill with outdated information, and retrieval noise increases. These costs are not symmetric for all memory types. For preference memories, over-decay is probably more costly. For session notes, under-decay is the greater risk.
Not every access is equal. Reading a memory to answer a question may reinforce its weight. Marking a memory as outdated should accelerate decay or remove it immediately. Confirming a decision should reset its decay clock. Define these access patterns explicitly — and decide which ones modify the decay trajectory and which ones don't.
In the lab, you'll calibrate a decay curve for a memory tier you describe. I'll help you work through the type taxonomy, select a function shape, justify the parameters, and define the reinforcement interaction rules.