Invalidation Without a Cron Job: Pheromone Evaporation
Every knowledge base that lives long enough accumulates facts nobody trusts anymore, and every system that stores knowledge has to decide, somehow, what to do about that. A personal-scale memory system can handle it the simplest honest way available: a script surfaces staleness candidates (entries whose age has outrun the commits landed since they were written) for a human to review by hand, and nothing gets deleted without that review. That’s the right answer at one person’s scale, where every entry represents a real correction that cost something to learn and there’s exactly one reviewer available who can make the judgment call.
It stops being the right answer well before tier 3. A production system absorbing writes from hundreds of thousands of sources doesn’t have “a human reviews staleness candidates” available as an option: there is no reviewer who could keep pace with that volume, and building a queue for one to try would just relocate the bottleneck rather than remove it. Tier 3 needs invalidation that happens automatically, continuously, and correctly, without a person in the loop for the ordinary case. This article is about the mechanism this series lands on for that: pheromone-style evaporation, with as much time spent on precision as on the idea itself, on exactly what part of applying it here is actually new.
Why “invalidate, don’t discard” was already right, and why it isn’t enough alone
The principle a well-designed personal memory system already follows (never delete a memory outright, mark it stale and let it be superseded) traces back to a rule used by Graphiti, the memory engine surveyed two articles ago: invalidate, don’t discard. The reasoning holds up at any scale: a fact that’s wrong now might have been true then, and a system that deletes on suspicion loses the ability to reason about what changed and when. Keep it, mark it, move on.
What that principle doesn’t answer is who marks it, and at what cadence. At personal scale, the answer was explicit and periodic: a staleness-sweep script runs occasionally, checking age against commit activity, and a human decides what to do with what it finds. That’s a batch process: something has to actually run, on a schedule, and do the checking. At production scale, a batch sweep has the same problem the human reviewer had: it doesn’t run continuously, so there’s always a window where stale information sits fully trusted, and running it often enough to close that window against hundreds of thousands of writers means the sweep itself becomes a significant, continuously-running piece of infrastructure, doing work that scales with corpus size on every single pass.
What evaporation actually replaces
Ant colony optimization (old, well-established literature, not something this series invented) solves a structurally similar problem for real ants: a pheromone trail marking a good path to food doesn’t get erased by a supervisor deciding it’s stale. It just fades, continuously, unless ants keep walking it and reinforcing it. No ant is in charge of forgetting. Forgetting is a property of the trail itself, expressed as a function of time since last reinforcement.
Apply the same shape to a knowledge-base entry instead of a physical trail, and the mechanism translates directly: every entry carries a strength value. Every time a write reinforces it (an agent’s query surfaces it and finds it useful, a regression result confirms a known failure signature again, a human’s correction gets validated by a later event), the strength goes up. Absent reinforcement, strength decays as a function of elapsed time. Below some threshold, the entry stops being surfaced by default, exactly like Graphiti’s invalidation — still present, still inspectable, just excluded from ordinary retrieval until something reinforces it back above the line or a human goes looking for it specifically.
The useful property this buys, and the reason the chapter title says “without a cron job”: decay computed this way doesn’t need a batch process to do anything at all. Current strength is a pure function of stored values (initial strength, decay rate, timestamp of last reinforcement, current time) computed at read time, the instant a query touches the entry. Nothing has to periodically walk the whole corpus checking ages against thresholds the way a staleness sweep does. The “sweep” is implicit in every single read, at zero marginal infrastructure cost as the corpus grows, because it was never a separate pass over the data — it’s arithmetic performed on the one entry a query already touched.
Worked concretely, with a standard exponential-decay formula, the arithmetic is this simple: strength halves every fixed interval (a half-life) without reinforcement, and every reinforcement resets the clock back to full strength. That reset-to-full rule is a deliberate simplification worth flagging rather than passing off as a literal transplant of the ant-colony update rule: real ACO reinforcement adds an increment to existing trail strength rather than resetting to a ceiling. Reset-to-full is simpler to reason about and to implement, at the cost of not distinguishing an entry reinforced once from one reinforced fifty times; that tradeoff is a design choice, not something borrowed wholesale from the biology.
This also gives reset-to-full a name in the literature instead of leaving it an unlabeled simplification. The general case, where reinforcement adds a linear increment rather than resetting to a ceiling, is Coppersmith and Diaconis’s Edge-Reinforced Random Walk. Linear reinforcement specifically buys a clean theoretical result: by de Finetti exchangeability, a linearly edge-reinforced walk is provably a mixture of Markov chains. Reset-to-full isn’t a linear increment, so it doesn’t inherit that guarantee. What it buys instead is structural, not theoretical: the write is a blind SET strength = 1.0, not a read of the old value followed by a computed one, so there’s no read-modify-write race to guard against. That’s a side effect of the simpler rule, not a mechanism bolted on afterward — and it matters later in this article.
Tune the half-life to two weeks, and an entry reinforced an hour ago is still, for all practical purposes, at full strength the next time it’s queried — an hour is a rounding error against a two-week half-life. The same entry, untouched for six weeks (three full half-lives), is sitting at one-eighth its original strength the moment anything finally queries it, quietly below whatever threshold gates default retrieval. Nothing ran in the background during those six weeks to make that happen. Nothing was scheduled to check in at week two, or week four. The number simply was what the formula says it was, computed once, the instant something finally asked.
Readers who know caching better than ant colonies already have a one-node version of this: LFU-with-aging applies the same idea to a single counter instead of a graph, and ARC’s trick of balancing recency against frequency, rather than picking one, previews the entrenchment problem the next section raises.
Is this actually new, or is this just ant colony optimization with extra steps
This is the question worth answering as precisely as the rest of this series has tried to answer everything else, because “pheromones for AI” has real momentum as a phrase and it’s worth separating the load-bearing claim from the evocative one.
Evaporation itself is not novel. It’s three-decade-old optimization literature. Applying stigmergic, environment-mediated coordination to LLM agents specifically is also not novel at this point — a system called AMRO-S, checked directly in this series’ opening article, routes queries across a pool of language models using literal ant-colony pheromone specialists, with asynchronous updates decoupling inference from learning, and it’s real, mechanistically specified, and working. And a live, first-party AWS blog post describes shared multi-agent memory where stored facts carry a confidence field that decays over time: real, shipped, in production, today.
None of those, individually, is the specific claim this article makes. AMRO-S’s pheromones govern routing (which model handles a query), not which facts a shared knowledge base still trusts; its pheromone matrix is a routing table, not a fact store, and updating it never touches anything an agent could retrieve as a memory. AWS’s confidence decay is real and directly relevant: its own documentation names retrieval and validation as reinforcement, reducing the confidence value for memories that “haven’t been reinforced by retrieval or validation,” but reinforcement there is a passing mention with no specified mechanism, no formula, no code, unlike the decay side, which ships with worked examples. It’s a flat per-fact metadata field decaying on a fixed schedule with an unspecified bump on use, not a reinforcement-and-evaporation system with both halves worked out, which is the actual pheromone-trail property that makes ant colony optimization work in the first place: good paths get walked more, and walking is what keeps them strong. The specific combination — evaporating strength as the general invalidation mechanism for a shared, multi-writer knowledge base, with reinforcement-on-use built in as the thing that keeps useful entries alive without any human or batch process deciding to keep them — didn’t turn up anywhere in this series’ opening prior-art search, across roughly thirty sources checked directly. The pieces are established literature; this particular assembly of them is where this design departs from precedent.
That search is now months further on, and the 2026 agent-memory landscape got more crowded in exactly this direction. HeLa-Mem ships explicit Hebbian synaptic plasticity for LLM-agent associative memory. A-MEM does Zettelkasten-style linking driven by access patterns. At least three smaller open-source projects — synaptic-memory, brain, mnemoria — now advertise Hebbian-style reinforcement as a headline feature. Evaporation-as-invalidation for agent memory, stated that broadly, is no longer a claim this series can make alone, and it shouldn’t try to.
The claim worth defending is narrower, and still unclaimed by any of them: edge reinforcement under concurrent, heterogeneous writers, not agents alone, but regression suites, telemetry pipelines, and humans writing to the same store, the distinction the previous article spent its whole length on. Add two conditions none of those projects meet: a bounded floor, so the mechanism can’t collapse into permanent winner-take-all starvation, and a logged candidate set, so a later pass can correct for the system’s own retrieval bias instead of mistaking “never surfaced” for “not useful.” None of the Hebbian-reinforcement projects checked do either. They reinforce; nothing found bounds it or logs around it.
There’s a sharper argument than a performance claim, too. A wrong answer traced through a bounded, logged edge is one specific row with one specific history, the way a bad answer is diagnosable in Zep’s validity-windowed graph, surveyed two articles ago. A wrong answer surfaced from additive storage plus a reader model doing the reasoning is a prompt-level forensics exercise with no equivalent row to point at. That’s the version of “is this actually new” worth standing behind: not the mechanism alone, which borrows openly and says so, but this specific combination, under this specific writer model, bounded and auditable in a way the current field doesn’t do together.
What has to be designed carefully, not just declared
Three things this mechanism doesn’t answer by itself, named honestly rather than left implicit. First, decay rate isn’t one number: the previous article’s distinction between writer types matters again here. A regression result that stops recurring is good news (decay is correct behavior: the bug got fixed, stop surfacing it as an active concern), while an agent-written fact that stops being queried is ambiguous (decay might be correctly retiring something nobody needed, or might be quietly losing something that was still true but temporarily out of focus). Different writer types plausibly need different decay curves, not one global constant, and getting that wrong in either direction either buries stale information under artificially slow decay or evaporates load-bearing knowledge because nobody happened to query it during a quiet period.
Second, reinforcement-on-use has a feedback-loop risk any recommendation system with a popularity signal eventually runs into: if being retrieved is what keeps an entry strong, and retrieval ranking favors strong entries, a fact that gets surfaced early purely by chance can entrench itself regardless of whether it deserves to, while something more useful but newer never accumulates enough reinforcement to compete. Recommender-systems literature has a name for this precise failure, “feedback loop amplifies biases,” and documents it as routine rather than hypothetical. The counter-mechanism this design adopts is a floor, not a fairness scheme: strength is clamped to a minimum value above zero rather than left free to decay without bound. That’s the same move Stützle and Hoos make in MAX-MIN Ant System, to keep every path selectable no matter how long it’s gone unreinforced. A floor doesn’t make a new or rarely-tested entry win on merit. It guarantees the entry stays visible enough to be reinforced again if it does deserve to, rather than decaying into a value indistinguishable from zero and unrecoverable except by a human going looking for it specifically. That’s a narrower promise than “converges to the right answer,” and the narrower promise is the one actually being kept here.
Third: it’s fair to ask whether evaporation inherits the concurrency hazards the rest of this series spent real effort on. The honest answer is narrower than it looks. Reset-to-full, the rule this design actually adopted, is a blind SET strength = 1.0, not a read of the current value followed by a computed one. Two writers reinforcing the same entry at the same instant don’t produce a lost update the way the earlier concurrency article’s TOCTOU bug did, or the way the previous article’s bucketing writer does: both just set the same value, whichever commit lands last determines the stored timestamp, and neither needs a lock or a read-then-write. Reading strength (the decay computation) and writing it (reinforcement) need no coordination beyond what an ordinary database transaction already gives a single-row update. That’s a consequence of choosing reset-to-full over the literal ant-colony increment rule, not a guarantee that comes free with evaporation as an idea. A future revision that needs per-writer-type decay curves badly enough to switch to an incremental update — reinforcement adding to existing strength instead of resetting it — would reintroduce the same read-modify-write shape, and would need the same concurrency discipline the earlier articles built. Decay alone doesn’t earn a free pass.
The next article picks up the piece none of this has addressed yet: not what to forget, but what to actually learn — whether the usage signal this article leans on for reinforcement can close a real loop into something smarter than a decaying number, the way this series’ opening article found essentially nobody has done for agent memory specifically.