We built memory that retrieves the right note every time, then watched it hand us a note that had quietly stopped being true. Retrieval was never the hard part. This is the fix we tried that failed the same afternoon, and the smaller thing we ship instead — one that does not pretend to know whether a note still holds.
The note was correct when we wrote it.
Weeks later, it lied without changing a single word.
I had asked an AI agent for the latest state of our launch work. It did exactly what I had trained it to do: search the team's memory, find a relevant record, and answer confidently. The record said a task was still waiting to be done.
The work had actually been finished weeks earlier.
In the same session, the agent found an old SEO audit and reported its unresolved items as our current problems. That list had been accurate on the day it was written. We measured the live site again; nearly every item had since been fixed.
We found both cases while dogfooding our own product before launch. They were not stories about a database losing data or a model failing to retrieve it. Retrieval worked perfectly. The agent found the right notes and gave the wrong answer.
That distinction changed what I thought an AI memory product needed to solve.
We solved finding the note, not trusting it
Most conversations about AI memory focus on recall: can an agent recover a useful fact after the chat ends? Can another tool or teammate find it later? Can the system rank the relevant note above the noise?
Those are real problems, and the industry has made them much easier.
But recall is only half of memory. The other half is currentness: is the retrieved fact still true?
A stale note does not look broken. Its text is intact. Its embedding still matches the question. Its source may be trustworthy. In fact, the more authoritative and relevant it appears, the more confidently an agent may repeat it.
The dangerous memory is not the one the system cannot find. It is the one the system finds immediately, cites correctly, and should no longer believe.
Our first fix was a label. It failed immediately
Our first design felt obvious: ask the writer to label each record as either a durable rule or a point-in-time observation.
A rule—"API errors use Problem Details"—could be reused without constant warnings. An observation—"the migration is still pending"—would carry a date and invite rechecking.
Then we sampled six of our own records at even intervals. At least four did not fit either box.
One note documented a durable implementation rule, the reason for it, the status of the rollout, and the fact that its commit had not yet reached the main branch. Half of the note could remain useful for a year. One sentence became false a few days later.
Mark it as a rule and the expired sentence escapes scrutiny. Mark it as an observation and the agent warns about a rule we want it to use every day.
The writer was also the worst person to make the distinction. The agent writing that mixed note believed it was documenting a completed fix. It did not know that one small sentence—"this commit is not on the main branch yet"—was a timer with no alarm.
We had tried to attach an expiration policy to the container. The facts inside the container expired at different times.
Age is not evidence
The next tempting fix was simpler: make old memories suspicious.
That fails in both directions. A year-old architecture rule may still be exactly right. A note written today may already be wrong.
We saw the second case in a particularly sharp form. An answer arrived in a review thread. Forty-four seconds later, a separate record said we were still waiting for that answer.
The record was false at birth.
Any rule that asks "did the world change after this was written?" misses that case, because the world changed first. Any rule that treats recent notes as safer gives the wrong note more authority precisely because it is new.
Time matters, but age does not prove truth. A timestamp is evidence for the reader, not a verdict from the system.
What we can show without pretending to know
Once we stopped trying to classify truth, the design became more modest.
When an agent reads a record, we can show two kinds of evidence beside it:
- when the record was written;
- the current state of any task or question the record explicitly names.
If an old note says a piece of work is pending while the task board says done, the contradiction is visible at the moment of use. If a note says a question is unanswered after a reply has arrived, the reader can see both claims together.
We deliberately do not label the record "current." We have no verification history that would justify that word. We also do not label it "stale," because age alone proves nothing. We do not hide it or silently reorder it.
The system presents the note, its date, and live evidence from named objects. The agent—and ultimately the human responsible for the decision—has to resolve the difference.
That may sound less magical than an automated truth score. It is also much harder to mistake for certainty.
A memory receipt you can use now
You do not need a specialized product to make team memory safer. Start by separating durable rules from observations and giving every observation a receipt.
MEMORY RECEIPT
Durable rule
- Rule:
- Why it exists:
- Scope:
Point-in-time observation
- Observed fact:
- Observed at:
- Verified by: command, URL, person, or source
- Depends on: task, question, branch, deployment, or owner
- Recheck when:
Do not put both sections in one record just because they came from the same conversation. They have different lifetimes. A rule can survive while the rollout status beneath it expires.
When evaluating any memory system, ask whether it preserves this evidence. Does it show when the note was written? Can it show the present state of the things the note names? Does its interface avoid implying that "no warning" means "verified"?
If the answer to all three is no, better recall may only help an agent retrieve obsolete confidence faster.
The part we have not solved
Evidence can still be ignored. An agent may quote the old sentence and skip the status shown beside it. A human may prefer the convenient answer. Notes that mention no structured object have nothing live to compare against.
The stronger solution begins when the record is written: store the subject, the claimed state, and the observation time as structured data instead of asking a later reader to infer them from prose.
We are not there yet. Until then, showing provenance and live contradictions is a guardrail, not a guarantee.
This account is from one team, one codebase, and our pre-launch dogfooding at LOOSEDAYS. It is not a benchmark, and the sample of six records is not a population study. It was enough to disprove our first design for our own work.
What this changed in Vibsync
Vibsync is the shared brain we build at LOOSEDAYS for teams using AI coding agents. After these incidents, we changed the read experience so a retrieved memory carries its recorded date and the live status of tasks or questions it names.
The goal is not to declare what is true. It is to stop an old statement from arriving alone, stripped of the evidence needed to question it.
That matters because different agents and sessions inherit the same record. A sentence written as temporary context can become tomorrow's starting point for someone who never saw the surrounding conversation. Shared memory amplifies useful knowledge. It also amplifies outdated assumptions unless current evidence travels with it.
If you want to try the Memory Receipt first, copy the template above into the document your agents already share. If you want agents on different tools and machines to inherit the same dated records, decisions, and live task context, connect them to one Vibsync team.
Vibsync is built by LOOSEDAYS Co., Ltd. This is a first-hand account of one team's pre-release work, not a controlled comparison.
Originally published at https://vibsync.com/blog/ai-memory-has-no-expiration-date.
Top comments (0)