Your facts expire. Your vector store doesn't know which.

A prospect asks your sales agent for a component’s list price. The agent answers instantly, sounds certain. The number is from January. It’s July. Procurement repriced the part in June, the new document sits in the same index, embedded as carefully as the old one, and the agent still picks the wrong price, because nothing in a vector store told it January’s answer had expired.

The upgrade from a vector store to temporal knowledge graph agent memory is a clock: every fact-edge knows when it became true and when it stopped, which is the difference between memory and a pile of true-once facts. That is a narrower, harder problem than most teams think they are solving when they add a vector database and call it memory. This post defends one claim: an agent’s memory is not done when it can retrieve a fact, it is done when it can retrieve the fact that is still true, and that requires representing time as a first-class part of the data, not as a lucky side effect of when a document happened to get written.

The naive fix: embed it once, retrieve it forever

The naive architecture is everywhere because it is genuinely good at the problem it was built for. You chunk your documents, embed each chunk, and at query time you find the chunks whose embeddings are closest to the question. It is fast, it is cheap, and for static knowledge, a product manual, a definition, a policy that never changes, it works close to perfectly.

It fails the moment a fact has a lifespan shorter than the document that states it. Picture a distributor whose list price for a component was $40 through the first half of the year and $52 after a June repricing. Both facts live in the index. Both are well-formed, well-embedded, semantically about “list price for this component.” Cosine similarity has no opinion about which one is current, because similarity is a measure of topical closeness, not truth over time. If the January document happens to be phrased slightly closer to how the question was asked, or was embedded with a model that scores it marginally higher, it wins, and the agent states it with the same confidence it would use for the correct number.

A vector store has no time axis at all, which is a distinct failure from the one an index goes stale describes. That post is about representation drift, an embedding model updates and you re-embed on a schedule to keep the index current with itself. This post is about something the re-embed job cannot fix: the fact itself expired in the world while the text describing it, and its embedding, stayed byte-for-byte identical. You can re-embed the January price note every night for a year and it will keep being a perfect, freshly-computed vector for a number that stopped being true in June.

Re-embedding fixes the index. It does not fix the fact.

This distinction is worth sitting with, because it is the one teams skip. The instinct, once you notice retrieval returning outdated answers, is to treat it as a freshness problem and reach for the freshness fix: re-index more often, add a recency boost to the ranking function, decay old chunks’ scores over time.

Recency boosting helps in exactly one case, when newer is reliably truer, which is common for a news feed and false for structured business facts. A contract renewed at a worse rate does not make the old contract’s terms less real, they were real, for a specific window, and an agent negotiating a renewal needs both the old terms and the exact date they stopped applying. Read alongside the contract that renewed at a worse rate: a system that only knows “newest wins” cannot answer “what did we agree to before this happened,” often the highest-stakes question in the room.

What you actually need is not fresher vectors, it is a record of validity per fact, something that says this specific claim, list price equals $52, held from June 14 onward, superseding a prior claim that held from January 3 to June 14. That is not a property of a document. It is a property of an edge between two entities: the component, and its price.

The mechanics of temporal knowledge graph agent memory

Once you accept that validity belongs on the fact, not the document, the natural structure is a graph. Entities become nodes, a customer, a component, a contract, an account owner. Facts become edges between them, and each edge carries a pair of timestamps marking the window it was true, commonly written as valid_from and valid_until.

The naive graph version of this still fails in a subtler way: if a new fact simply overwrites the old edge, you gain an ordering guarantee but lose history. You can no longer answer “what did the system believe on March 3rd,” and if the correction itself turns out wrong, there is nothing to roll back to.

The fix is a bi-temporal model that never deletes, only marks. This is not a new invention, bi-temporal data modeling has been standard practice in database theory since Snodgrass’s work on temporal databases in the 1990s, tracking both when something was true in the world and when the system recorded it. ApolloSpace AI’s memory layer is built so this discipline runs underneath every agent, not just one of them: it is the System of Record every agent reads before it answers and writes back into after it acts, so the same valid_from/valid_until pair that models the component’s price also models an account owner’s handoff, a contract’s renewal term, a customer’s plan tier, anything an agent could otherwise assume is still true because nobody told it otherwise.

Zep’s Graphiti engine, described in Zep’s technical paper on temporally-aware knowledge graphs, was an early and influential proof that this exact discipline belongs specifically inside agent memory rather than only inside a database textbook; its own t_valid/t_invalid naming for the same pair of timestamps is worth crediting here as the reference this design learned from.

The upgrade from a vector store to temporal knowledge graph agent memory is a clock: every fact-edge knows when it became true and when it stopped, which is the difference between memory and a pile of true-once facts. That is the whole engine described above, restated: not a bigger index, a validity window on every edge, sitting underneath every agent ApolloSpace AI runs.

A fact that cannot say when it stopped being true is not a fact your agent can trust, it is a guess wearing a timestamp it does not have.

This is also where the field’s vocabulary is worth crediting rather than claiming. Graph-based retrieval augmented generation, GraphRAG, is Microsoft Research’s term for grounding generation in a knowledge graph rather than flat text chunks; the GraphRAG versus vector search framing on this blog covers why that fight is usually mis-posed as either-or. What ApolloSpace AI owns is the layer above both ideas: the bi-temporal graph as System of Record, the agent runtime reasoning over it as System of Intelligence, and the write it makes back after it acts, a quote sent, a renewal escalated, an owner updated, as the System of Action closing its own loop, so the three kinds of memory an agent needs build on one clock instead of three vendors trusting each other to agree.

Retrieval that answers “what’s true now,” not “what was true once”

The upgrade from a vector store to temporal knowledge graph agent memory is a clock, and retrieval is the moment that clock actually gets checked. The payoff shows up at query time. A naive graph query walks every edge connected to an entity and hands the agent all of them, current and superseded together, and asks the model to sort out which one applies, which is asking a language model to do bookkeeping it was never given the timestamps to do reliably.

This is the query ApolloSpace AI’s agent runtime is built to run instead of a similarity search: stamp the query with a point in time, almost always “now,” and filter at the database layer for edges whose validity window contains that instant, before a model ever sees a candidate answer. Take the sales agent from the opening scene: it does not pull every price edge and hope the prompt nudges the model toward the recent one. The System of Intelligence layer issues one as-of-now query against the System of Record, gets back the single currently-valid price edge, and the System of Action layer answers with it, then writes back the fact that it quoted, and when, as its own new edge, closing the loop instead of leaving the quote to live only in a chat transcript. The agent never sees the superseded price, and it is excluded by a WHERE clause on a timestamp, not a ranking heuristic that might guess wrong.

This is the difference between an agent that was told the truth and one that was handed everything and asked to guess which part was still true. The clearest public evidence for why a memory layer is worth building this way, not proof of ApolloSpace AI’s own numbers but the strongest case on record for the mechanism, comes from Zep’s published benchmarks on exactly this kind of point-in-time filtering: on the Deep Memory Retrieval benchmark, temporally-aware graph memory scored 94.8 percent accuracy with GPT-4-turbo against a 93.4 percent MemGPT baseline; on the harder LongMemEval benchmark, the same approach answered at 71.2 percent with GPT-4o against a 60.2 percent full-context baseline, while cutting response latency from roughly 28.9 seconds to 2.58 seconds and the context window from about 115,000 tokens down to 1,600; Graphiti’s own retrieval, run without an LLM call, reports a P95 latency of 300 milliseconds. Filtering by validity is not just more correct, it is cheaper and faster at the same time, the same shape of win ApolloSpace AI’s memory layer is built to produce for every agent that reads it, not only the one in a benchmark.

What this costs, honestly

None of this is free, and pretending otherwise is the fastest way to lose a reader’s trust. A temporal graph asks more of ingestion than an embed-and-forget pipeline does. Every new fact has to be checked against existing edges for contradiction before it can be written, which in Graphiti’s design means a semantic and graph search pass, and often a model call, on every write, not just on every read. That is write-amplification: paying a cost at ingestion time so you do not pay a much larger, silent cost at answer time.

There is also a lock-in cost. Once memory lives in entities and time-stamped edges rather than flat embeddings, you cannot swap in whichever vector database has the best benchmark this quarter, the graph is the substrate now. And a graph is more operationally visible than a vector store, contradictions have to be resolved by some policy, most systems default to trusting the newest evidence, and that policy needs to be right, because it is doing judgment work a similarity score used to do implicitly and badly.

The trade is worth making anyway, because the alternative cost is invisible until it is expensive: an agent that confidently quotes a dead fact to a real customer, with no record of when it became wrong, a failure mode that belongs in the memory layer’s design from day one, not as a patch bolted on after the first wrong quote reaches someone who mattered.

The turn

Underneath the timestamps and the edge schemas, this is about something much more human than database design. Every team has a colleague whose information is technically accurate and practically dangerous, the one who still quotes last year’s org chart, the vendor terms before the renegotiation. They are not lying. They simply never updated the clock in their head, and everyone has learned, quietly, to double-check anything they say before repeating it.

An agent with a vector store and no temporal layer is that colleague, at scale, answering with total confidence every single time. The fix was never to make it sound less certain. The upgrade from a vector store to temporal knowledge graph agent memory is a clock, and that is the same upgrade the overconfident colleague needs too: not a way to sound less certain, but a way to know, structurally, that some of what it remembers has an expiration date, the same way a person who reads the news learns which of their beliefs need revisiting and which ones still hold.

---

This is the standard worth building an agent’s memory layer toward: facts as entities and time-stamped edges, not flat embeddings, so an agent answers with what is true today and can still show its work for what used to be true and when that changed. It is an extension of the same idea behind giving agents full context of your operation — context is only useful with a clock attached. Get that right, and the prospect asking about that component still gets an instant answer, just the June number now, with July’s date attached to why.