Temporal Graphs: Teaching an Agent That Facts Change Over Time

A user tells your agent, in March, that they're planning a wedding. In September, they mention their honeymoon. In November, offhand, they mention their spouse. Nothing about these three facts contradicts anything — they're a coherent timeline of a life event unfolding. But now imagine the user, back in January of the following year, mentions they're "not with anyone right now." A memory system with no concept of time has three facts asserting a relationship and one fact denying it, with no principled way to know the denial is the current truth and the others are history.

This is the exact class of problem that temporal graphs exist to solve, and it's why Zep — built on the open-source Graphiti engine — has become a default reference point for anyone building agent memory that needs to survive contact with real, changing human lives. Graphiti turns conversations, documents, and structured data into an evolving graph where facts aren't just stored, they're timestamped, connected, and versioned as understanding of the user changes.

The core idea is almost embarrassingly simple once you say it out loud: a fact isn't just true or false, it's true during a specific window of time. Most memory systems don't model that window at all.

Why "just store the latest version" isn't good enough

The naive fix for changing facts is to overwrite: when the user says something new, replace the old value. This works for genuinely simple cases — a phone number update, a name change — but it destroys information that often still matters. If a user asks "wait, when did I tell you I moved to Seattle," an overwrite-based system has no answer; the old fact is simply gone, replaced with no record it ever existed or when the transition happened. For any agent that needs to reason about change itself — how a project evolved, how a user's situation developed, what was true when a decision was made — overwriting is a data-loss strategy dressed up as a simplification.

A temporal graph keeps both facts, each attached to a validity window, and lets the query determine which one is relevant. "What's the user's city" resolves to the current value. "When did the user move" resolves to the transition itself. Both questions are answerable from the same underlying structure, because the structure preserves history instead of discarding it.

Retrieval that knows the difference between "was true" and "is true"

The mechanical trick that makes this useful rather than just theoretically tidy is that Graphiti's retrieval combines vector search, full-text search, and graph traversal, and critically, can filter or weight results by their temporal validity. A query about the user's current employer can be scoped to facts still within their validity window; a query specifically about the user's history can deliberately include facts outside it. That distinction — present-tense query versus historical query — is something a flat vector store simply cannot make, because embeddings carry no notion of time at all. Two facts that are semantically similar but temporally exclusive (old job, new job) look identical to a similarity search; only a structure that explicitly encodes time can tell them apart at retrieval.

This connects directly to the contradiction-handling problem raised in What an Agent Should Forget — a temporal graph doesn't need a separate "forgetting" mechanism to handle stale facts, because staleness is a first-class property of the data model, not an exception the retrieval logic has to detect and route around after the fact.

Multi-session reasoning is where this stops being optional

For a single conversation, temporal reasoning barely matters — facts asserted five minutes ago are, by default, the current ones, and a sliding context window handles that correctly without any special machinery. Temporal graphs earn their complexity specifically in the multi-session case: an agent that talks to the same user across weeks or months is guaranteed, eventually, to encounter facts that changed between sessions, and an agent with no temporal model will either confidently assert something outdated or, worse, hedge on everything because it can't distinguish current from historical with any confidence.

This is the throughline connecting temporal graphs to the broader argument in Why Graph-Native Memory Is Winning Over Pure Vector Stores — the value of structure over flat similarity search compounds specifically as an agent relationship gets longer and the underlying facts get less static. A one-off Q&A tool never encounters this problem. A companion agent that's been talking to someone for a year encounters it constantly, and the products that handle it gracefully are the ones that modeled time as a real dimension of memory from the start rather than trying to patch it in after users started noticing inconsistencies.

What a temporal graph makes possible that flat memory doesn't

Beyond just avoiding contradictions, temporal structure enables a genuinely different class of agent behavior: reasoning about change, not just around it. An agent that can see a user's employment history as a timeline, rather than a single current-state fact, can notice patterns — a user who's mentioned three job changes in eighteen months might benefit from different framing on a career-advice question than one who's been stable in a role for a decade. None of that reasoning is possible from a memory system that only ever keeps the latest snapshot; it requires the history to still exist, structured well enough to be queried as a sequence rather than reconstructed from scattered, undated fragments.

This is also where temporal graphs meaningfully help with the governance questions raised in The Privacy Question Nobody Answers When They Ship Agent Memory — a system that already tracks when each fact became valid has a natural audit trail for "when did we learn this," which is exactly the provenance question a privacy review will eventually ask, and exactly the kind of answer a flat, undated memory store cannot produce after the fact.

The cost side of the ledger

None of this is free. Temporal graphs are more complex to build, more expensive to query at scale than a flat vector lookup, and require more discipline at ingestion time — every extracted fact needs to be timestamped and, ideally, checked against existing facts for contradiction or supersession, not just appended. For products with genuinely simple, static memory needs — an agent that only ever needs to know a handful of durable, rarely-changing facts about a user — this complexity is pure overhead, and a simpler store is the right call.

But for the products where memory is actually load-bearing — where users return over months or years, where their situation genuinely evolves, where getting a stale fact wrong is embarrassing rather than harmless — a temporal graph isn't a nice-to-have sophistication layer. It's the only architecture that models the actual shape of the problem: not "what does the agent know," but "what does the agent know, and since when, and is it still true." Building memory that ignores the "since when" is building memory that will eventually, confidently, tell a user something about themselves that stopped being true months ago — which is a worse failure than forgetting outright, because it comes wrapped in false confidence.

Part of the "Agent Memory" series on aiskill.market.