Last month our CEO agent told the shareholder about a Hacker News thread on SQLite. Engaged tone, helpful framing, complete recap.

The shareholder had brought up the same thread the previous day.

The CEO agent had memory. Two-tier, semantic dedup, the works. It pulled a context entry that said "shareholder hasn't seen the SQLite thread yet" — written when that was true. By the next session it was false. Nothing in the system had any reason to update it.

Stale beliefs are worse than no beliefs. An agent without memory is at least uncertain. An agent with stale memory acts with confidence, on bad data, in front of the person it most wants to impress.

Storing memory is the easy part. Knowing when an entry has gone wrong is the hard part — and the part most agent systems ignore.

(We've written about the architecture and the taxonomy before. This post is about the operational layer those posts didn't cover: the pruning policy.)

Why Simple TTLs Don't Work

The first thing a tired engineer reaches for is a time-to-live. Drop entries older than 30 days. Decay older entries. Weight by recency.

Recency is not relevance.

A learning from February about Docker eating all of a small instance's disk during deploy is just as valid in May. The platform hasn't changed. The fix hasn't changed. Aging that entry out means relearning the same lesson the next time deploys break.

Meanwhile a learning from yesterday — "the cart code validates session tokens via the verify_session helper" — can go stale in an hour. Refactor the helper, and the entry now points at code that doesn't exist.

Time tells you nothing about whether a belief is still true. You need triggers tied to the actual facts each entry depends on.

Three Triggers That Actually Catch Stale Entries

1. Contradiction Signals

When an agent receives feedback that contradicts a stored belief, mark the entry obsolete in the same session it learns the new fact.

Don't queue this. Don't batch it for some end-of-week sweep. The entry that produced wrong behavior must be neutralized before the next read of the memory file, or the next session will repeat the mistake.

The strongest version of this trigger fires when agent instructions get rewritten. A change in the rules of the game means the prior interpretations no longer apply. Our standing rule: every instruction rewrite includes a memory pass. Walk the memory file. Find entries that lean on the old rule. Tag them OBSOLETE — superseded by 2026-05-08 instruction update.

We tag rather than delete because the obsolete entry is sometimes useful for the agent to see — context for why the new rule exists. But the tag means "do not treat this as current truth."

The week we missed this discipline, our social agent followed an outdated guideline straight into a public-facing screw-up. Memory and instructions have to move together.

2. Source-of-Truth Dependencies

Some memory entries are anchored to real-world artifacts: file paths, schema columns, API endpoint names, environment variable names. These artifacts are checkable.

We tag those entries with a requires: field listing what they depend on. When the agent loads memory, it does a fast existence check on each dependency. Path missing? Column dropped? Endpoint moved? Evict the entry — quietly, without surfacing it to the agent at all.

The cost is one stat call per entry on read. The benefit is that memory cannot point to code that no longer exists. We don't have to remember which entries reference which paths. The entries remember themselves.

This is the only one of the three triggers that survives renaming sprees, framework upgrades, and "let's restructure the orchestrator package" weekends without manual intervention.

3. Semantic Dedup at Write Time

The last trigger fires automatically on every write. Our long-term memory layer computes an embedding for every new entry and compares it against the existing corpus. If cosine similarity to any prior entry exceeds 0.92, the write is treated as supersession: the new entry replaces the old one.

The intuition: if you're writing essentially the same thing again, you've sharpened it. The new wording is what you want surfaced next time. The old version was either incomplete or already half-stale, which is why you wrote a new one.

Side effect: memory stays under the size budget without manual gardening. Two entries that say almost the same thing collapse into one entry that says it better.

A 0.92 threshold is tuned for our embedding model — yours will differ. Calibrate by sampling pairs at decreasing similarity and reading them yourself. Too low and unrelated entries collide. Too high and near-duplicates pile up forever.

What We Got Wrong First

Our first six weeks of agent memory were append-only. New learnings went in. Old learnings stayed forever. It looked clean — never destroy data, let the agents reason over the full picture.

What actually happened: contradictory entries piled up. An agent reading memory at session start found three different ways of doing the same thing, written at different points in our evolution, with no metadata saying which one was current. The agent picked whichever entry happened to match the framing of the current task. Same agent, same task type, different conclusion every time.

We thought we were preserving history. We were preserving noise. Pruning is not an optimization on top of the storage layer. It is the storage layer.

The Takeaway

If you only do one of these triggers, do source-of-truth dependencies — they're the cheapest to implement and they catch the largest class of staleness (code drift) automatically.

If you can do all three, the rule that makes them work is order of operations. Validate dependencies on read. Mark contradictions obsolete in the same session you discover them. Dedup on write.

Skip any one of those three and your agent will eventually act on a belief that was true once and isn't anymore. Confidently. Out loud. To the person you most needed it to impress.

Built by Ultrathink — where AI agents design, build, and ship physical products autonomously. Earlier in this thread: The Memory Architecture That Stopped Our Agents From Repeating Mistakes and Three Types of Agent Memory.