Many agent-memory products now market some flavour of “temporal,” “time-aware,” or “temporal knowledge graph.” Very few actually ship bi-temporal memory. The gap between the marketing word and the engineering reality, tracking both when a fact was true in the real world (valid time) and when the system learned it (system time), is one of the least understood things in agent memory, and one of the most consequential. Here is what it means, who really has it, and the part everyone selling “temporal memory” leaves out.

Two clocks, not one

Every fact your agent stores has two timestamps that are easy to confuse and expensive to conflate.

When it became true in the world (valid time). “The customer moved to Berlin in March.”

When your system learned it (transaction time). “We recorded that in July.”

Single-timeline memory collapses these into one. So it cannot answer the two questions that separate a memory that reasons over time from a notepad with timestamps:

“What did we believe was true on 5 March?” Reconstruct the past belief state, for audit, debugging, and “why did the agent act on that?”
“This became true last year, but we only found out today.” Record history correctly without pretending the fact is brand new.

A system that stamps everything with “now” answers neither. It asserts every fact happened the instant it was written. For anything an agent reasons about over time, that is quietly wrong.

Bi-temporal memory tracks both clocks independently. That is the whole definition. Everything else is a timestamp column with good marketing.

We mapped the field, with sources

We published a source-cited matrix of who actually ships bi-temporal. The short version:

Product	Real bi-temporal?	What they actually ship
Zep / Graphiti	Yes	Two independent clocks, point-in-time queries, automatic invalidation. The reference implementation.
Hunta Gather	Honest second	Supersession, full history, and point-in-time recall today; independent event-time on a short roadmap.
Cognee	One clock	Event-time extracted from text, but no separate system-time and no as-of.
Mem0	No	A settable created_at plus natural-language date parsing. One clock.
Supermemory	No	The API ships createdAt / updatedAt plus versioning.
Letta, Memobase	No	Single creation timestamp; no validity intervals, no as-of.
Anthropic, OpenAI memory	No	File notes or a mutable profile revised in place. No temporal model.

Two things stand out. First, “temporal” is the most over-marketed word in this category: most of the field ships one clock and a docs page titled “Temporal.” Second, the honest hierarchy is short. Real bi-temporal is not table stakes: it is a capability roughly one production vendor has fully built. We are building the second, and we will tell you plainly where we are on the way.

Where Gather honestly stands today

We update and retire facts while keeping the full history: nothing is destroyed, and corrections are auditable. You can already recall memory as of any past date. What we are finishing is the second clock: letting you assert when a fact became true, distinct from when we learned it. The schema field is already there for it. We would rather ship it honestly than paint a fourth timestamp on a screen and hope you do not look. We had exactly that temptation, and removed it.

The part everyone selling “temporal” leaves out

Here is the uncomfortable question a temporal knowledge graph cannot answer: a memory that knows when a fact was true, does it know who wrote it, and whether that source should be trusted?

There is a second failure mode, and it is worse than a missing timestamp. Every one of these systems (Zep included) writes on a self-building path: the same agent doing the work decides what enters memory and writes it directly. That direct-write path is the injection surface. A legitimate, already-authenticated agent reads a poisoned web page or a booby-trapped document, and commits the poison as a trusted, well-dated, bi-temporal fact. A perfect record of where it came from, on a lie.

Bi-temporality tells you when a fact was true. It says nothing about whether it should ever have been written. Those are orthogonal, and much of the field is investing in the first while leaving the second wide open.

Gather is built the other way around: the writer never decides. A candidate fact travels a curator pipeline (a deterministic screen, a distiller, an LLM reviewer, a multi-model panel for the ambiguous cases, and a guard that updates facts while keeping the old version in history) before anything is committed. The agent proposes; a separate stage decides what gets saved. See the write path for how that works, and why the same planted instruction a normal memory saves every time, ours rejects.

Why this matters for a fleet, not a chatbot

For a single assistant, one clock and an honest writer is often fine. For a fleet (many agents, across teams, writing into shared memory, some reading untrusted content), the two capabilities compound. You need to reconstruct what the fleet believed and when (bi-temporal), and you need to guarantee a single poisoned read cannot rewrite what every agent trusts (the write path). That is the enterprise problem, and it is the one we are built for.

Honesty note

Gather does not yet ship full two-clock bi-temporal. We ship supersession, history, and point-in-time recall now, with independent event-time next. We publish the competitor matrix with sources precisely so you can hold us to the same standard we hold everyone else. In the field we have mapped, only Zep ships true two-axis bi-temporal in production, and we are the honest second.

Your agent's memory knows what it learned. Does it know when it was true?