Temporal Agent Memory: When Facts Change
Use event time and validity intervals to answer current and historical questions. Learn when a temporal knowledge graph helps and test a SQL baseline.
Temporal agent memory keeps track of when information was true, not just when the application stored it. A temporal knowledge graph represents those changes on entities and relationships. A simpler table with validity intervals can also work when the questions do not require graph traversal.
Start with the question the agent must answer. “Who manages this account now?” and “Who managed it when the incident happened?” can have different correct answers. Retrieving the most recently imported document does not reliably answer either one.
What is a temporal knowledge graph?
A knowledge graph represents entities and their relationships. A temporal knowledge graph adds time information to those facts or relationships, such as the period during which a person managed an account.
A conceptual fact might be:
subject: account_42
relation: managed_by
object: person_7
valid_from: 2026-01-01
valid_until: 2026-03-01
source: assignment_event_103This application record treats the beginning as inclusive and the end as exclusive. Define that convention explicitly so a change at midnight does not create two conflicting “current” assignments.
Not every fact has a known end date. An open interval usually means no end has been recorded; it does not prove that the fact remains true forever. Freshness and source-authority rules still matter.
Event time, validity time, and ingestion time
| Time | What it describes | Why the distinction matters |
|---|---|---|
| Event time | When something happened or was said | Reconstructs the sequence of events |
| Validity interval | When the claim applies | Answers current versus historical questions |
| Ingestion time | When the application received the record | Diagnoses processing lag and late arrivals |
Suppose a customer preferred phone contact in January and changed to email on March 1. An archive import in April brings in the January conversation. That record is newly ingested, but it is not the newest preference.
Keep the original event date and the applicable scope. If the archive cannot establish when a statement was true, preserve that uncertainty instead of treating import time as a substitute.
Can a database answer historical questions without a graph?
Yes. For a small number of explicit facts, validity filtering may be sufficient. This SQLite-compatible query selects facts valid on a requested date for one authorized tenant and subject:
SELECT value, source_id
FROM preference_history
WHERE tenant_id = :tenant_id
AND subject_id = :subject_id
AND preference_key = :preference_key
AND valid_from <= :as_of
AND (valid_until IS NULL OR :as_of < valid_until);Use consistently formatted dates and a defined timezone when storing timestamps. The application must supply authorized identifiers. This query does not perform authentication, infer missing dates, or resolve overlapping contradictory intervals.
Test the transition date, earlier history, another tenant and a late import. If it returns conflicting values, surface the conflict or apply a documented resolution policy; adding LIMIT 1 would only conceal the ambiguity.
A graph becomes useful when the answer needs several changing relationships: who managed the account, which team that person belonged to, and which policy applied to that team at the time. Measure whether graph traversal improves those questions enough to justify the additional modeling and operating work.
How should corrections preserve history?
Separate a correction to a wrong record from a real-world change. “The meeting was actually on Tuesday” corrects the historical account. “Future meetings move to Tuesday” changes the schedule from a point onward. Both contain similar words but require different updates.
Store the source and reason for a consequential correction. If the product must answer “what did we believe at the time?”, preserving only the current interpretation of history is insufficient. That requirement needs a record of when knowledge was recorded or revised as well as when the underlying fact applied. The simple validity query above does not implement that second history.
For user-facing controls, use the memory lifecycle guide. Correcting a current answer, suppressing retrieval, and deleting stored source material are different outcomes.
Does recency weighting solve temporal memory?
No. Recency can help rank candidates, but the newest statement may describe an old event, concern a different project, or come from a less authoritative source. It may also be a task-specific exception rather than a permanent change.
Apply scope, source, and validity checks before treating a similarity or recency score as evidence that a fact is current. For a live transactional decision, fetch the current system of record. Remembered prose should not override a current access policy or account state.
RAG can include timestamps, filters, and historical records. It does not inherently discard time. The RAG versus agent memory guide explains how retrieval and lifecycle policy fit together.
What does Supermemory document about changing facts?
Supermemory's graph-memory documentation describes update, extension, and derivation relationships. Updates can make a new fact current for search while retaining history; related graph fields distinguish current information. These are useful capabilities to test against your corrections and historical questions.
Map your application's time fields to the documented API operations. Keep any additional validity intervals in application-owned records when historical queries require them.
Graphiti provides another documented temporal graph approach. Compare architectures using the same questions and source histories rather than assuming a graph guarantees the right interpretation of every change.
Historical recall is different from predicting the future
Answering who owned a project last month is a historical retrieval problem. Predicting who will own it next month is a forecasting problem. A production assistant may need the first without needing the second.
A temporal representation helps organize evidence; it does not turn an uncertain future event into a known fact. Keep forecasts labeled and evaluate them separately from factual recall. Do not choose an architecture on the assumption that every agent requires extrapolation.
Build a temporal-memory acceptance test
Use a small fixture with an old fact, a clear replacement, a project-specific exception, a late-arriving old record, and a question with an unknown date. Ask both “now” and “as of” questions. Include the exact boundary where one interval ends and another begins.
Check the returned evidence as well as the final answer. A model can select the wrong value even when both relevant records were retrieved. The LongMemEval guide explains benchmark coverage of changing facts, and the memory debugging guide helps trace application failures.
Start with explicit dates and a simple representation. Add graph relationships when they answer a question the baseline cannot handle reliably. The goal is an agent that can explain which fact applies and why, without confusing newly imported history with a new reality.
If changing user facts are part of your workload, evaluate Supermemory with a small revision history. Test which evidence is returned before and after a correction, and verify any historical-query requirement separately against the documented API.