Last night I was deep in a build session with an AI assistant. We picked it
back up tonight. At some point I mentioned it had been a day and a half since
we last spoke — and the model had no idea. None. As far as it knew, it was
still the previous session. The gap was invisible to it.
That tiny moment is one of the most underrated problems in AI systems right
now. So let's talk about it.
The model doesn't know what time it is
An LLM gets a rough sense of "now" at the start of a conversation — a single
timestamp, handed to it once. That's why it can greet you with "good morning."
But that stamp is frozen. It doesn't update as the conversation runs, and it
definitely doesn't travel into the next conversation. Each session starts
cold.
On its own, that's a curiosity. It becomes a real problem the moment the model
reasons over retrieved context — search results, documents, database rows,
another agent's output.
Staleness is invisible
Here's the dangerous part. When a model reads a retrieved document, that
document usually carries no trustworthy signal about when it was true. So the
model treats it as present-tense. It produces a confident answer from
six-month-old data with nothing flagging that the data is old.
A few places this bites:
- Pricing — quoting a number that changed last quarter.
- Availability — "in stock" from a cached page.
- Compliance — citing a policy that was superseded.
- People — stating someone's job title from two years ago.
For a human reader, a slightly stale search result is fine — you see the date
and judge for yourself. For an LLM, the staleness is silent. The wrong answer
looks exactly like a right one.
Why "just add a clock" doesn't fix it
The instinct is: give the model the current time. But knowing it's 9 PM doesn't
help if the document you're citing went stale in 2023 and nothing told you. The
missing piece isn't the model's clock — it's the context's freshness.
Two different things:
-
What time is it now? — easy, a
now()call solves it. - How old is this piece of information, and can I trust that claim? — this is the real gap.
To know whether something is stale right now, you need two numbers: when the
information was true, and the current time at the moment you check. The second
has to be sampled fresh every time you evaluate — not inherited from when the
session started.
A cleaner way to think about it
Borrow the GPS model. GPS doesn't work by making every receiver smart enough to
know the time. Satellites broadcast signed, timestamped signals, and the
receiver compares them against its own current clock to compute position. The
intelligence is in the signal, not the receiver.
Apply that to context:
- Stamp each piece of retrieved context with when it was true and when it was retrieved.
- Attach a decay model — because "6 months old" means worthless for a stock price and totally fine for a math proof. Age alone is meaningless without knowing how fast that kind of fact decays.
- Carry that metadata with the context as it moves through your pipeline, so it doesn't get stripped at the first hop.
- Evaluate freshness against the current moment each time the context is read — not once at retrieval and then frozen.
Now the model doesn't need to "know what time it is." The context tells it
whether it's still safe to use.
The takeaway
If you're building anything that retrieves context and reasons over it — RAG,
agents, internal knowledge tools — staleness is a silent failure mode. The fix
isn't a smarter model. It's giving your context a sense of time: when it was
true, how fast it decays, and whether it's still valid right now.
The model that lost a day and a half wasn't broken. It just had no signal. Most
AI systems don't.
I'm building in this space — a context integrity layer that stamps retrieved
context with signed freshness and provenance. Happy to talk shop with anyone
working on similar problems.
