Most memory failures are not caused by an agent knowing nothing. They are caused by an agent confidently using something that used to be true.
People change roles. Customers change success metrics. Deadlines move. Preferences depend on context. A risk can be resolved and later recur for a different reason. If memory stores these as timeless sentences, retrieval becomes a contest between frequency, recency and semantic similarity. None of those reliably equals current truth.
Temporal memory makes change explicit.
Use two kinds of time
A strong temporal model distinguishes at least two clocks.
Observed time is when the system received or recorded the information. Effective time is when the information became true in the world.
These can differ. A CRM import on 20 June may report that a person changed roles on 1 June. A meeting summary written Friday may describe a decision made Wednesday. A user correction today may explain that a stored preference has been wrong for months.
If the system tracks only ingestion time, it can misorder reality. Effective time should therefore be a first-class field when the source provides it, with uncertainty when it does not.
Current state should be derived, not overwritten
A simple key-value store encourages overwriting: role = “VP Operations” becomes role = “Chief Operating Officer.” That provides the current value but destroys the history.
A temporal memory keeps versions:
- VP Operations, effective 2023-03-01 through 2026-05-31;
- Chief Operating Officer, effective from 2026-06-01;
- source and observed time for each assertion.
The current view can be derived from these versions. Historical retrieval remains possible, and an agent can understand why an older meeting referred to the previous title.
This pattern applies to priorities, relationships, preferences and commitments—not only roles.
Supersession is not contradiction
When a person changes their mind, the new statement often supersedes the old one. Both can have been valid at different times.
A contradiction is different: two claims purport to describe the same period and cannot both be true. For example, the CRM says the renewal decision maker is Maya while a recent executive email says Daniel owns the decision. Until the discrepancy is resolved, the system should not quietly select one.
Represent at least three relationships between claims:
- supersedes: the new claim replaces an earlier one from a later effective time;
- conflicts with: both claims compete for the same time or state;
- refines: the new claim adds specificity without invalidating the earlier one.
These relations let retrieval expose the right level of uncertainty.
Preferences need context and expiry
“Prefers email” sounds like a stable fact, but preference is often conditional. A person may prefer email for contractual decisions, Slack during a launch and text for urgent travel changes.
A useful preference record includes:
- object of preference: channel, format, timing or interaction style;
- context: which task or relationship it applies to;
- strength: explicit request, repeated behavior or weak inference;
- first and last supporting evidence;
- expiry or review condition;
- contradicting evidence.
This prevents a one-off instruction from becoming a permanent personality attribute. It also helps the agent phrase the memory appropriately: “Maya explicitly requested email for approval records” is more precise than “Maya prefers email.”
Commitments have a lifecycle
A commitment is inherently temporal. It moves through states such as proposed, accepted, due, completed, moved, cancelled or disputed.
Do not create a new disconnected commitment every time the deadline changes. Maintain one object with versioned updates:
- action and owner;
- beneficiary or counterparty;
- original due date;
- current due date;
- status transitions;
- completion evidence;
- source for each change.
This makes overdue logic and briefing logic dependable. It also distinguishes “not done” from “no longer required,” which a transcript search can easily confuse.
For the founder workflow, commitments are one of the most important objects in a selective morning briefing.
Recurrence should not revive stale causes
Suppose an account had a permissions issue in February, resolved it in March, and reports a new permissions issue in July. A text-only memory may revive the old incident as if it remained open. A temporal model can create two issue episodes connected by a shared topic.
This distinction matters because the response may be different. The July issue could affect different administrators or result from a new configuration. Historical similarity is useful context, but it is not current state.
Model recurring conditions as episodes with start, updates and resolution. Link episodes when useful, but do not collapse them into one timeless problem.
Source authority is temporal too
Source reliability is not fixed. A project plan may be authoritative before launch and stale afterward. An executive decision can override a template. A support ticket may accurately report symptoms but not commercial priority.
Temporal reconciliation should therefore consider:
- the source’s authority for this field;
- whether the statement is direct or quoted;
- its effective time;
- whether a later source explicitly confirms or reverses it;
- whether the author is still in a relevant role.
This is why “latest document wins” is insufficient. The latest document may be a copied artifact with old content.
Retrieval should ask temporal questions explicitly
A generic query such as “What do we know about Maya?” encourages an undifferentiated profile. Better retrieval requests state a temporal intent:
- current priorities for tomorrow’s renewal call;
- changes since the last executive meeting;
- commitments due in the next seven days;
- historical relationship context explaining the current concern;
- unresolved conflicts affecting this decision.
The result can then be organized into current state, recent change, open obligations and uncertainty. The how-it-works overview describes this task-shaped retrieval boundary.
Corrections may rewrite effective time
User corrections are not always simple edits. “That role change happened in March, not June” modifies the effective interval. “She never preferred weekly reports; that was only during onboarding” narrows the context and may invalidate several derived summaries.
A correction workflow should:
- retain the user’s correction as evidence;
- update or supersede the affected claim;
- recompute current-state views;
- identify derived memories that relied on the old version;
- preserve the audit trail;
- prevent stale caches or indexes from continuing to serve the old claim.
Correction propagation is part of memory quality. Updating a row while leaving derived embeddings and summaries untouched is not a complete correction.
Evaluate with sequences, not isolated questions
Temporal behavior cannot be evaluated from single snapshots. Build test sequences:
- establish an initial role or priority;
- repeat it in several documents;
- introduce a later change from an authoritative source;
- quote the old state after the change;
- ask for current state and historical explanation;
- add a correction to the effective date;
- verify that retrieval updates consistently.
Other useful sequences include moved deadlines, resolved-and-reopened issues, temporary preferences and conflicting sources.
Metrics should include current-state accuracy, supersession accuracy, conflict visibility, correction propagation and false revival of resolved events.
A minimal temporal schema
You do not need a specialized temporal database to begin. A durable claim can start with:
- subject ID;
- predicate and value;
- observed_at;
- effective_from;
- effective_to, nullable;
- status: current, historical, superseded, conflicting, uncertain;
- epistemic type: explicit, extracted, inferred, directed;
- source reference;
- supersedes or conflicts_with IDs;
- scope and owner.
The important step is not the storage engine. It is refusing to represent changing facts as timeless text.
Design the current view carefully
Most product surfaces should not force users to inspect the full temporal graph. They need a concise current view with change cues.
A good rendering might say:
Renewal measure changed from activated seats to weekly adoption on 18 April, based on the executive sponsor’s email. A May support template still references seats and appears stale.
That sentence communicates current state, change, evidence and a relevant conflict. It is more useful than returning three source chunks and asking the user to reconcile them.
The current view should remain inspectable: users can open the supporting evidence and historical versions when needed. This balance—compact output with preserved lineage—is central to the memory-quality model.
Temporal memory does not make an agent omniscient. It gives the agent a disciplined way to say what appears current, what used to be true and where the system is still unsure. For long-lived relationships, that is the difference between recall and continuity.