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, and — as much time on precision as on the idea itself — 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 — genuinely 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 genuinely 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 genuinely 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.
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.
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 genuinely 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.
What has to be designed carefully, not just declared
Three things this mechanism doesn’t answer by itself, worth naming honestly rather than leaving 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 genuinely stale information under artificially slow decay or evaporates genuinely 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 genuinely more useful but newer never accumulates enough reinforcement to compete. This needs an explicit counter-mechanism — something that gives new or rarely-tested entries a fair chance to prove themselves rather than starting in a hole they can never climb out of — not just an assumption that reinforcement alone converges to the right answer.
Third, and most important given everything the rest of this series has established: evaporation is an invalidation mechanism, not a concurrency mechanism. It says nothing about what happens when two writers reinforce the same entry at the same instant, or when a reinforcement write races a decay computation. That’s exactly the read-modify-write shape the earlier articles in this series spent real effort getting right, and evaporation inherits that requirement rather than replacing it — a strength counter is, mechanically, the same kind of shared mutable state a naive lost-update race lives in, just serving a different purpose. Getting evaporation right means building it on top of the concurrency discipline already established, not treating it as a separate concern that happens to also touch the same data.
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.