Bi-temporal memory for AI agents: what was true, and when

Your support agent tells a customer they are on the Pro plan. They downgraded three weeks ago. The memory layer had both facts, "Maria is on Pro" and "Maria moved to Free", with nearly identical embedding scores, and the retriever picked the stale one.

This is the most common way agent memory fails in production, and better retrieval does not fix it: the store holds two facts about Maria and has no way to say which one is still true.

Bi-temporal memory fixes this by giving every fact two clocks. This post explains what that means, how we built it in Korely, and what it costs.

Bi-temporal memory stores each fact with two time axes: valid time, when the fact was true in the world, and transaction time, when the system learned it. A new fact that contradicts an old one closes the old fact's validity window instead of deleting it, so the agent reads current truth by default and can still ask what was true, or what it knew, on any past date.

The idea is older than LLMs. Bi-temporal tables have existed in databases for decades (SQL:2011 added system-versioned and application-time periods). What is new is applying it to facts that a model extracts from conversation, where contradictions arrive as free text instead of as an UPDATE statement.

When "the EU server costs 40 euro" is followed a month later by "the EU server now costs 50 euro per month", a memory layer can do one of three things.

The second row is not hypothetical. One published memory system describes a DELETE operation "for removal of memories contradicted by new information" in its base pipeline, while its graph variant marks conflicting relationships "as invalid rather than physically removing them" (Chhikara et al., 2025, arXiv:2504.19413, sections 2.1 and 2.2).

We are also not the only ones doing the third row. The temporal knowledge graph of Rasmussen et al. "implements a bi-temporal model" with four timestamps on each edge and invalidates contradicted edges by setting their end to the start of the new one (Rasmussen et al., 2025, arXiv:2501.13956, sections 2.1 and 2.2.3). If you are choosing a memory layer, bi-temporality is the property to look for, whoever provides it.

Korely extracts typed facts from what your agent writes: a subject, a predicate and an object, with the predicate normalized into one of 10 families (preferences, people, places, work, ownership, health, financial, events, identity, other). Each fact carries:

There is no status column. A fact is current when valid_from is not in the future and invalid_at is null or still ahead. The two timestamps carry the state.

Closing a fact is a write-time decision, in two stages. The first stage is cheap and deliberately over-matches: it looks for open facts that could be about the same thing: the same subject and relation (costs 40, costs 50), facts about the same two entities under another relation (uses Jira, stopped using Jira), and the nearest facts by meaning.

The second stage shows a model the new fact with its candidates in one call and asks which of them can no longer be true. "Marco likes tea" leaves "Marco likes coffee" true: both can hold. "The EU server costs 50 euro per month" means "the EU server costs 40" is no longer true. Only a confirmed conflict closes the old fact.

Because all of this happens when the memory is written, reading is a database lookup with no language-model call. Extraction runs asynchronously and settles within a few seconds of the write, so a read issued immediately after a write may not see the new facts yet.

as_of answers what was true on a date, as the store knows it now. known_as_of answers what the store knew on a date. They differ when a change is reported late, which in real conversations is most of the time.

The agent already knows that a customer lives in Milan. Send that first memory with timestamp set to when it was true (for example timestamp="2026-08-01"), because a memory without a timestamp is valid from the day it is written, and a later report dated earlier does not close it. On 5 October the agent learns that the customer moved to Turin on 1 September 2026:

The first call is what you want when the agent acts today. The second is what you want when someone asks why the agent sent a parcel to Milan on 20 September: on that day, Milan was the right answer given what it knew. The second call returns Milan only if the Milan memory was really written before 20 September. If you replay or backfill the memories later, it returns an empty list for that date, because the store learned the facts on the day of the write.

A full history, with every closed fact and what closed it, is one flag:

known_as_of depends on closed_known_at, which Korely has recorded since 11 October 2026. For facts closed before that date the value is estimated from what was stored, so read older history as approximate.

Closing facts is paid for at write time: an extraction call, model calls that place each relation the store has not seen before among the ones it knows and decide whether it holds one value at a time, and a judge call for the new facts that have candidates. A write takes a few language-model calls, and longer memories take more, because the engine reads them in windows of up to 6,000 characters, one extraction call each. Reads cost nothing in language-model calls, because they are lookups.

The trade-off is latency on the write path. If your agent writes a fact and reads it back in the same second, design for the few seconds of asynchronous extraction.

The free Hobby plan includes 250 writes a month (one per memory up to 6,000 characters), stored in the EU. Add --processing-region eu if the memories must also be read by a model in the EU. Install the SDK, write two contradicting facts, and read them back with include_invalidated=True:

The temporal model is documented in full in Temporal facts, and every read parameter is in the API reference.