Some of what you know has a shelf life
Not all knowledge ages the same way. A decision or constraint stays true until someone changes it; an operational fact — a service is running, a host is reachable — is only true as of the moment it was checked, and can flip with no one updating the record. Treating both the same is how a memory quietly serves stale "facts." The fix: mark the time-varying ones and re-verify just those when they pass a freshness window — not relitigate everything.
Two facts, two lifespans
“David prefers parallel delegation” and “the sync service is running” are both facts, but they age on completely different clocks. The first is durable: it holds until someone decides otherwise. The second is volatile: it was true when it was checked, may be false an hour later, and — the dangerous part — nobody will file an update when it flips. A memory that scores both by the same slow clock will keep handing you the volatile one long after it went wrong.
Age-decay is the wrong tool for volatile facts
Letting knowledge fade over months is exactly right for durable facts that stop being renewed. It is useless for “is the daemon up.” You do not want that to slowly lose confidence over half a year — you want it treated as unverified within hours, and you want to be told to re-check it. Decay answers a different question (“is this getting old?”) than volatility does (“has this been confirmed recently enough to rely on?”).
Mark it, then re-check just it
The move is small. Tag the time-varying facts for what they are, give them a freshness window, and let the memory surface the handful that have gone past it — these need a re-check — instead of re-examining the whole corpus. You re-verify a few operational facts; you do not relitigate every decision you ever recorded.
And re-checking a volatile fact and finding it still true is real evidence, not noise — it refreshes the fact’s currency. This is the one place where saying the same thing again is valuable rather than redundant, and a memory worth trusting knows the difference.
Why this keeps the memory honest
The failure it prevents runs both ways. Without it you trust stale facts — the service “is running” when it crashed an hour ago. But you also wrongly distrust still-true ones — you assume a connection got fixed because something upstream changed, when the specific thing never did. Both are errors of currency, and you only catch them by re-verifying the parts of the world that move.
So the durable facts hold, and the moving ones get checked. That division is what lets a shared memory stay current without drowning you in re-confirmation — forgetting what should fade, and re-asking only what genuinely might have changed.
Frequently asked
Doesn't everything go stale eventually?
Durable facts — decisions, constraints, preferences — stay true until deliberately changed, so slow decay is right for them. Volatile facts — operational state — can flip with no update filed, so they need a short freshness window and active re-checking, not patient decay.
Isn't re-checking the same fact just repetition?
For a durable fact, repeating it adds nothing. For a volatile one, confirming it is still true at a new moment is fresh evidence — it refreshes the fact's currency. A good memory treats the two cases differently: repetition is noise, re-verification is signal.
Related
Take yourself out of the loop.
Let your agents do the lifting while you keep the judgment.
Get the Playbook