Short answer: Temporal memory tracks that facts change over time, so the system can tell what was true when and what is true now.
A correctly stored fact can later become wrong. Temporal memory records validity, updates, and supersession instead of freezing forever on the first write. That is how agents handle preference drift and outdated claims without treating every old note as current.
Scoping settles who a memory belongs to, but it says nothing about whether that memory is still accurate. A fact captured correctly on the day it was written can quietly stop being true weeks later, and nothing about its scope, its topic, or the way it was originally stored gives any hint that this has happened. Handling that gracefully, rather than either freezing on outdated information or losing the history of how things actually changed, is what temporal memory is about.
Why Does a Memory System Need to Care About Time at All?
The world a memory system is trying to track doesn’t hold still. A person’s job changes, a project’s status moves from planning to shipped to deprecated, a household’s internet plan gets upgraded, a patient’s medication dosage gets adjusted. If a memory system only ever knows the latest thing it was told, without any sense of when that thing became true or what it replaced, it’s implicitly assuming nothing it stores will ever need correcting, an assumption that fails constantly in any system running for more than a few days.
Temporal memory means treating “when was this true” as a first-class part of a fact, not an afterthought. This is different from just overwriting a value whenever new information comes in, because overwriting silently destroys the history of what used to be true and when it stopped being true, information that’s sometimes exactly what’s needed later.
What’s the Difference Between Simply Updating a Fact and Actually Modeling Its History?
Simple overwriting treats a fact like a variable: there’s a current value, and every update replaces it, with no trace of what came before. This works fine when only the current state ever matters, and nobody will ever need to know that a value used to be something else. A lot of memory genuinely fits this pattern, and forcing history-tracking onto it everywhere would just add unnecessary complexity.
Modeling history means the fact carries an explicit sense of validity over time: this was true starting on this date, and it stopped being true (or was superseded) on that date. This matters whenever the sequence of change is itself informative, not just the endpoint. Knowing that a person’s job title changed twice in the last year tells a different story than just knowing their current title, even though the current title alone would be enough for plenty of everyday interactions.
When Does the History Actually Matter, Rather Than Just the Current State?
History becomes valuable whenever a decision or explanation depends on the sequence of events, not just where things ended up. A support agent troubleshooting a recurring issue benefits enormously from knowing this is the third time a particular setting has been changed, not just what it’s currently set to, because that pattern itself is diagnostic. A financial advisor explaining a portfolio’s current allocation benefits from knowing when and why previous allocations shifted, since the reasoning behind past changes often shapes what advice makes sense now.
In plenty of other cases, though, the current state really is all that matters, and preserving every past value would just be clutter competing for attention with the one fact that’s actually relevant right now. The two questions worth asking before deciding are: would knowing the sequence of past values change how this fact should be used today, and is there a real chance of needing to answer “what was true as of some earlier point in time” later. If both answers are no, plain overwriting is the right choice, and adding temporal tracking would be solving a problem nobody has.
What Actually Goes Wrong When Time Isn’t Modeled at All?
Without any temporal awareness, a system can only reconcile two conflicting statements as a contradiction to resolve right now, rather than recognizing that one statement is simply the earlier truth and the other is the current one. This turns something that should be a routine update into something that looks like an error needing correction, and a naive reconciliation step might genuinely struggle to tell an actual contradiction (two things that can’t both be true at the same time) apart from an ordinary change over time (two things that were each true, just at different times).
Left unhandled, this produces exactly the kind of instability already covered when discussing conflicting memories in general: retrieval sometimes surfaces the old fact, sometimes the new one, with no reliable way to know which is current, because nothing in storage actually says which one came first.
How Does Weaviate Engram Handle a Fact Changing Over Time?
Weaviate Engram’s transform step resolves this by retrieving related existing memories before committing anything new, and using that comparison to decide whether an incoming fact is a fresh, unrelated detail or an update to something already stored. When it’s determined to be an update, Engram can rewrite the existing memory to explicitly capture the change, preserving the fact that a transition happened rather than silently replacing one value with another. Consider a property-management assistant tracking the condition and terms of a rental unit across a multi-year tenancy:
from engram import EngramClient
client = EngramClient(api_key=os.environ["ENGRAM_API_KEY"])
client.memories.add(
"Unit 4B's lease renewed at $1,850/month, up from $1,700, effective the new lease term.",
properties={"unit_id": "building-9-unit-4b"},
)
Because a prior memory already exists describing the unit’s previous rent, Engram’s transform step retrieves that earlier fact during processing and can rewrite it to explicitly capture the transition rather than just silently replacing the number: “Unit 4B’s rent was $1,700/month until the current lease renewal, when it increased to $1,850/month.” Searching for this unit’s history later surfaces that transition directly:
results = client.memories.search(
query="Has the rent for this unit changed, and when?",
properties={"unit_id": "building-9-unit-4b"},
)
What comes back isn’t just the current rent in isolation, it’s the actual story of the change, which matters enormously if a dispute ever comes up about what was agreed to and when. Meanwhile, a completely unrelated fact about the same unit, say a note about a recent maintenance request, gets stored as its own separate memory rather than being folded into the rent history, because nothing about it relates to what came before. Modeling time well means the system can tell these two situations apart: recognizing an update to something already known, and keeping a genuinely new, unrelated fact standing on its own.
Temporal memory deals with a fact changing while still describing the same underlying thing, the same tenant, the same rental unit, the same person’s job. A related but distinct question is what happens when a system needs to track two different kinds of information about that same underlying thing at once: a stable, always-current profile versus a growing list of individual things that happened to it. Our next chapter, What is the difference between profile memory and event memory?, turns to exactly that distinction.