Time Is the Missing Dimension of AI Memory

A stale fact is not a wrong fact. I keep coming back to that distinction because it's the one the tooling gets wrong.

If an agent's memory says the moon is made of cheese, that is wrong, and it was always wrong, and any sane system should reject it on sight. But if an agent's memory says "the billing service runs on its own Redis instance," that was true (written down by a careful engineer who checked) and it is now wrong, not because anyone lied, but because eight months passed and the world moved underneath the sentence. The fact didn't change. The truth value of the fact changed. Those are not the same thing, and almost no memory system I've looked at can tell them apart.

The bugs that ruined my weekends were never the loud ones. A crash hands you a stack trace and a place to start. The expensive bug was always the row that was correct the day it was written and quietly turned into a liability while nobody was looking: a feature flag left on past its incident, an exchange rate from last quarter, a config still pointing at a host that got decommissioned months ago. Every one of those was, underneath, a system that recorded what and threw away when. That's the instinct I brought to SmartMemory, a memory infrastructure layer for AI agents. The most underrated property in the whole space is the one nobody markets. Most memory systems know what. Very few know when. And for an agent that acts on what it remembers, "when" is not a nice-to-have field. It is the difference between "restart the service" and "do not restart the service or you will lose data."

Knowledge has a long shelf life. Expertise expires.

SmartMemory's thesis is that there is a layer above raw knowledge, and the layer is the valuable one. Knowledge is what's true. Expertise is what to do. "Postgres uses MVCC" is knowledge. It'll be true next year. "We migrated billing off the dedicated Redis in March, so the old flush runbook is dangerous" is expertise, and it has a shelf life measured in deploys.

Here's the part people miss when they reach for a bigger context window or a better embedding model: expertise is inseparable from time. A runbook is a snapshot of how the world was wired the day it was written. A user preference is true until the user changes their mind. A constraint ("don't call this endpoint, it's rate-limited") holds until someone raises the limit. The thing that makes a piece of expertise expertise rather than trivia is exactly the thing that makes it perishable: it's bound to a particular state of the world, and the world doesn't hold still. Store the expertise and drop the time, and what you've actually saved is last year's wiring diagram. Useful right up until the day someone trusts it.

This is the part of a memory system I'd defend hardest. Anyone can store text and retrieve it by similarity. The hard, unglamorous, decades-of-database-pain question is: of all the things I once recorded as true, which ones are still true right now, and how would I prove it?

The runbook that was right until it wasn't

Let me make it concrete, because abstractions about time put everyone to sleep.

An ops agent gets asked, "What's the command to clear the cache for the billing service?" Retrieval does its job. It returns a runbook snippet written by a real senior engineer, properly stored, high relevance score, no red flags anywhere. The snippet runs FLUSHALL.

The runbook was written when billing had its own dedicated Redis instance. Eight months ago billing moved to a shared Redis. The fact is true. It was true. Run today, FLUSHALL flushes the cache for half your services, and the incident you started with becomes the smaller of two incidents. Nothing in a naive vector-similarity retrieval encodes "true as of when" or "true in which version of the world." The memory was contextually correct at write time and catastrophically wrong at read time, and the retrieval layer had no way to know, because the only question it knows how to ask is "is this relevant?" The question it needed to ask was "is this still true?"

A model upgrade does not fix this. The error is not in the reasoning. The error is in the memory, and specifically in the missing dimension of the memory. It remembered the command and forgot the era.

One clock is not enough: valid time and transaction time

Now we get to the actual mechanism, and it's a thing databases settled decades ago and AI quietly forgot.

When you bolt a single timestamp column onto a memory and call it temporal, you have answered the wrong question. A single timestamp conflates two genuinely different clocks. You need both.

The first clock is valid time: when was this true in the world. Billing ran on its own Redis from, say, last June until this March. That is a valid-time interval, and it is a fact about reality, completely independent of when anyone wrote it down.

The second clock is transaction time: when did we learn it and record it. We might not have written the migration into memory until April, three weeks after it actually happened. We might have recorded the old runbook back in June and never touched the record again. Transaction time is a fact about the system's belief, not about the world.

Here is why you cannot collapse them into one number. With only one clock you can answer neither of the two questions that actually matter:

• "Is this still true?" is a valid-time question. You're asking whether the world the fact describes still exists. You answer it by checking the fact's valid interval against now.
• "What did the agent know when it made that decision?" is a transaction-time question. After an incident, you don't want to know what's true today. You want to reconstruct what the system believed at 03:14 when it ran the command. That means rewinding the agent's knowledge to its state at that moment, including the things it believed that have since been corrected.

I've sat in enough "explainable AI" conversations to know they dissolve the instant you ask the second question. The system overwrote its old beliefs, so it genuinely cannot tell you what it thought an hour ago. It can only report what it thinks now and assume, with great confidence, that it always thought that. That isn't an audit trail. It's a store that keeps exactly one version of the truth, the current one, and has no way to show its work.

SmartMemory is bi-temporal by construction. Every memory item carries a valid interval and a transaction time, and the version tracker keeps both clocks as first-class intervals: a valid_time_start/valid_time_end pair for the world, and a transaction_time_start/transaction_time_end pair for our belief. An open transaction-time end (no upper bound) is precisely how the system marks "this is the version I currently hold." That open-ended-means-current convention is small and it is the whole game. It lets you ask "what version was valid at time T?" and "what version did we believe at time T?" as two separate queries, because they are two separate questions. With one timestamp, both queries collapse into a shrug.

Supersession, not overwrite: because you cannot audit what you destroyed

The second mechanism follows directly from the first, and it's the one that violates most engineers' default instinct.

When a new fact arrives that contradicts an old one, the obvious move is to overwrite. The migration happened, so UPDATE memory SET fact = 'billing shares Redis' and move on. It feels like housekeeping, and it quietly destroys the only record of what the system used to believe. That record is the exact thing you'll be reaching for at 03:14 during the next incident.

SmartMemory does not overwrite. It supersedes. The old fact stays. The new fact is written, and an explicit SUPERSEDED_BY edge is drawn from the old record to the new one. The old version's transaction-time interval gets closed at that boundary, and the new version's opens there with no gap between them. The chain is the history: each SUPERSEDED_BY edge records one fact giving way to the next, so you can follow the links and see what the system believed and when each belief was retired.

Two consequences matter here. First, it's auditable. "What did we believe, and when did we stop believing it?" becomes a graph traversal instead of an archaeology project against backups. Second, it's reversible. If a supersession was wrong (a bad write, a misread, an over-eager background job that contradicted something it shouldn't have), you have not lost the prior state, because you never destroyed it. You can roll forward to the corrected version or walk back to the original. An overwrite gives you neither. The bytes are gone, and the postmortem ends at "root cause: unknown, state not recoverable." That's the worst line you can write in an incident review, because it's an admission that the system can't account for itself.

This is also why I keep insisting that supersession is a temporal mechanism and not just a fancy update. An update is a statement about now. A supersession is a statement about the boundary between two eras. It records not just the new fact but the precise moment one truth handed off to the next. You only get that if time is in the model from the start.

The fact that ages itself: "flying to Portland" becomes "flew to Portland"

There's a third class of temporal change, and it's the one that surprised me most, because it isn't triggered by a contradicting fact at all. It's triggered by nothing happening, by time simply passing.

Consider a memory written in June: "flying to Portland in July." Perfectly good fact. Future-tense, planned, anchored to a concrete date. Now it's August. Nobody contradicted the memory. No new information arrived. But the sentence is now wrong in a quiet, grammatical way. The trip is no longer in the future, it's in the past, and an agent that recalls "flying to Portland in July" in August is subtly out of sync with reality in a way that will eventually embarrass it.

SmartMemory has a temporal forward-aging path that handles exactly this. When a fact carries a concrete future date (a valid_end_time lifted from an absolute extracted date, never a guess, never a re-interpreted "next Tuesday") and that date elapses, the fact can be rewritten into its resolved past-tense form: "flew to Portland in July." Crucially, this is a distinct kind of change from the other two. Supersession fires when a contradicting fact shows up. Staleness demotion ranks an outdated fact down in retrieval. Forward-aging fires on the passage of time alone, on facts that nobody touched.

And, this is the detail I'd defend in a design review, it does it reversibly, through the same bi-temporal supersession machinery. The original future-tense statement is retained as auditable history. The past-tense version supersedes it. You can still ask "what did this memory say back in June?" and get "flying to Portland in July," because that's what it said in June, and the system did not lie about its own past to make its present tidier.

I want to flag the discipline here, because it's the thing that separates a careful temporal system from a dangerous one. Forward-aging only acts on items with a concrete, parseable, absolute date that has actually elapsed. An item without a hard temporal anchor is never a candidate, and nothing is ever inferred. There are memory systems that "dream," periodically re-reading their own contents and re-interpreting dates and phrasings in prose. That is a recipe for mangling "I'll see you in a week" into a wrong absolute date and then confidently aging that. We deliberately don't do that. We age what the world has objectively moved past, and we leave everything else exactly as written. Time is powerful precisely because we only let it act on facts that have a real clock attached.

Why a flat vector store cannot carry time

You can see, by now, why this is hard to retrofit. Time is not a column you sprinkle on at the end. Valid intervals, transaction intervals, supersession edges with handoff boundaries, age-once-and-only-on-elapsed-dates: these are relationships between versions of facts, and relationships are not what a flat vector index is for. A vector store can tell you that two snippets are similar. It cannot natively tell you that one replaced the other, when the handoff happened, which one was believed during which window, or that one is the resolved past-tense descendant of the other. Those are edges, and edges want a graph.

That's a big part of why SmartMemory is graph-backed rather than a single undifferentiated vector blob. The supersession chain is real edges you can traverse. The two clocks are real intervals you can query as-of. The context that makes a memory safe to act on (when was this true, when did we learn it, what did it replace) travels with the memory as structure, instead of evaporating at write time the way it does when you flatten everything into one searchable string and a similarity score.

When was this true?

If I could get every team shipping agents to add one question to their retrieval path, it would not be "is this relevant?" They've all got that one. It would be: when was this true?

Make every memory answer it. Give every fact a valid interval and a transaction time, so you can ask both "is this still true?" and "what did we know when?" Supersede instead of overwriting so the history survives the correction and the incident stays explainable. And let facts age forward against a real clock instead of pretending the world they describe is frozen at write time.

The model will keep getting better. It will not get better at knowing when. That's not its job. The expensive failures I've watched all had the same shape: a fact that was right at write time, acted on at read time, with nothing in between to say how much of the world had moved. Time is the in-between. It's the cheapest thing to record at the door and the most expensive thing to reconstruct after the fact. That's exactly why so few systems bother, and exactly why the ones that do are the ones I'd trust to act on what they remember.

The ops agent ran FLUSHALL for a reason that was good in June and lethal by November. It remembered the command and forgot the era. That gap, between the fact and the era it belonged to, is the missing dimension. Put time in the memory and the gap closes. Leave it out and you've built a store that knows everything except whether any of it is still true.

---

I'm building SmartMemory, the expertise layer for AI agents: provenance-tagged, bi-temporal, graph-backed memory that knows not just what's true, but what to do, and when it stopped being true.

Try it: pip install smartmemory (docs) · hosted beta (private): smartmemory.ai/signup