Watch anyone running multiple agent sessions and you will see the same behavior: copying the same context from one chat into another, over and over. The database schema. The deployment target. The naming convention the team settled on last month. The human has become a message bus between their own agents, re-explaining facts the system already derived yesterday.
That observation points at the practical core of agent memory. The ambitious version, an agent that remembers everything it has ever done, remains unsolved and probably stays that way for a while. But the modest version is buildable today and delivers most of the value: a shared fact store. One agent distills a fact, other agents read it, and nobody derives it a third time. Think of each repo or workflow as a team, and the fact store as what lets teams stop re-briefing each other from scratch.
The hard part is not storage. It is lifecycle. Facts rot. "We need more pipeline" is true today and misleading a quarter from now. Other facts get superseded rather than rotting: month-to-date sales are worthless the moment the new report lands, while daily sales records are true forever. A serious memory system distinguishes these cases, because they demand different handling.
And deletion is almost never the right move. Say a big deal closes and validates a hundred downstream assumptions. Then the deal falls through. Every one of those superseded facts just became live again. If you deleted them, your agents are now operating on a version of reality that no longer exists. Mark supersession explicitly, keep the history searchable, and make the current view slim. This is the same discipline that makes organizational context such a hard problem: the knowledge is not static, and pretending it is produces confident agents that are wrong.
The teams that get this right will not have agents with better memories. They will have agents that never waste tokens, time, or human patience rediscovering what the organization already knows. Start with the facts you find yourself pasting between sessions. That is your first schema.
Key takeaways
- The highest-leverage agent memory feature is preventing agents from re-deriving facts the organization already established.
- Facts have a lifecycle of derivation, sharing, superseding, and retirement, and a memory system must manage all four stages.
- Superseded facts should be marked, not deleted, because business reversals can make old facts true again.
FAQ
Why not just give agents full memory of everything?
Because most of what accumulates is noise, and stale facts actively mislead. Forgetting what is no longer relevant is strategically valuable. The goal is a curated store of durable facts with clear supersession, not a transcript archive.
What is the difference between a rotted fact and a superseded fact?
A rotted fact quietly lost relevance over time, like a priority that mattered a month ago. A superseded fact was explicitly replaced, like a month-to-date sales figure replaced by a fresher one. Systems should track supersession explicitly so it can be reversed if the replacement turns out wrong.
Related Essays
Agent Memory Is Unsolved. Workflow-Scoped Learning Is Not
General-purpose agent memory is still a research problem. The opportunity is workflow-scoped learning that compounds — pick the constraint, and the memory problem stops being intractable.
Organizational Context Is the Hardest Problem Nobody Has Solved
Context management is the layer most consistently built in-house and least well served by vendors. It is not a search problem. It is a knowledge management problem.
Facts Rot. Reports Supersede. Build Memory Accordingly
Organizational agent memory needs rot and supersession semantics. Facts have lifespans, and the fresh report that replaces yesterday's is the format LLMs actually need.
Drowning in pull requests that need your review? Try Tembo Review, a beautiful AI-assisted PR review tool unlike anything you’ve used.