Facts expire. A real memory remembers when.

The bitemporal model behind Graphiti, and why "what is true now" is a different question from "what did we know then."

Spaced recall (L5): what two ingredients make a knowledge graph, and what makes an edge precise? Nodes + typed edges; the type. Today those edges learn to expire.

The one idea: A vector store overwrites. When a fact changes, the old chunk is replaced and the past is gone. A temporal graph invalidates instead of deleting: every fact carries a validity window, so you can ask what is true now AND what was true at any past moment. That memory of change is what turns storage into memory.

The failure a flat store hits

"DuckyCutz's busiest branch is Phuket Town." True in June. Suppose Patong overtakes it in December. In a vector store you re-embed the new fact and the old one vanishes. Fine, until an agent asks "when did Phuket Town stop being number one?" or "what did we believe about branch traffic at the time we signed the contract?" The flat store cannot answer. It never kept the timeline.

Bitemporal: two clocks, not one

Graphiti tracks two independent times on every fact. This is the bit most people miss:

Clock	Answers	Example
valid time	When was this true in the real world?	"Patong led from Dec 1"
transaction time	When did the system learn it?	"We recorded it on Dec 9"

Two clocks because the world and your knowledge of it drift apart. You often learn a fact late, or learn today about something that was true last month. Separating "when it was true" from "when we found out" lets the agent reason about both reality and its own past beliefs. That is what bitemporal means.

Invalidate, don't delete

New fact arrives"Patong is busiest"

Old edge closedvalid_to set, not deleted

New edge openedvalid_from = now

Query by time"now" or "as of June"

Both edges live on. Ask for the current answer and you get Patong. Ask "as of June" and you get Phuket Town. Ask "when did it flip" and the timestamps tell you. Nothing was lost.

Why this beats batch GraphRAG for agents

Recall Microsoft-style GraphRAG: it batch-extracts the graph and precomputes community summaries. Powerful, but when data changes it must recompute large parts of the graph, and retrieval can take tens of seconds. That is fine for a static corpus, wrong for an agent ingesting meetings and calls all day. Graphiti's bet is real-time incremental updates: a new fact is integrated immediately, the affected edge is invalidated, no batch recompute. For live agent memory, that is the difference between usable and not.

Connect it back: this is exactly why your /handoff → /prime loop uses Graphiti and not a flat vector store. Sessions change what's true (a deploy lands, a decision reverses). Bitemporal edges mean /prime can load "what is true now" while the history of how you got there stays queryable. You picked the right tool; now you know why.

Retrieval practice

A fact changes. What does a temporal graph do with the old one?

What is the difference the two clocks capture?

Why is batch GraphRAG a poor fit for live agent memory?

Read this next (primary source)

★ Zep: A Temporal Knowledge Graph Architecture for Agent Memory (the research paper behind Graphiti's bitemporal model). Denser; skim the architecture section. ~20 min. Lighter alt: Neo4j's Graphiti overview.

Ask your teacher. Try: "query my Graphiti graph for a fact and show me its valid_from/valid_to", "would a DuckyCutz KB even need bitemporal, or is valid-time enough?", or "does gbrain do temporal, or just typed edges?" (it leans on git history for time, a different bet worth comparing).

← Lesson 5: Knowledge graphs Next → Lesson 7: Vector vs Graph vs Hybrid (the decision)