Sheaf

A comparative study of temporal memory architectures

When comparing agentic memory architectures, there are two orthogonal problems.

These are different graph problems with different consistency requirements. I kept treating them as the same database and they are not.

I Temporal knowledge base

Given a fact F and a time T, what should the system return now, and what should it have returned at T. This requires temporal semantics: versioning, valid-time ranges, point-in-time queries.

II Agent session memory

What this agent instance remembers across turns in a conversation. It can recall "Nora" as an entity while still holding a stale policy vector from three weeks ago.

This is a teaching simulation to separate the concerns. I run the same authored timeline through different memory architectures and score them against a gold temporal truth. I want to see which architectures confuse "what we know" with "what was true then."

Fig. 1 Signal sources and scoring target Authored inputs, no live APIs, gold standard reference

Memory products

Embeddings, transcripts, wiki snapshots. Recall tools. Not temporal truth stores without versioning.

This simulation

Same authored Acme timeline through multiple architectures on one clock. Architectures differ in update and expiry semantics.

Gold standard

What Acme should answer at time T. Temporal truth. Not what retrieved highest, what was actually true then.

Wiki, Slack, tickets, email, chat. These are labels on lines I wrote for Acme. No Slack webhook. No RAG benchmark. Testing temporal consistency, not retrieval quality.

Fig. 2 Layer distinction: company SST vs agent session memory Orthogonal problems, different consistency requirements

a Layer A: Company SST. What is X now. What was X at timestamp T. Cite source if required. Needs valid-time semantics, not just latest write wins.

refund=14 [T₁₄, now] refund=30 [T₀, T₁₄) query(T_now)

b Layer C: Session memory. Entity recall across conversation turns. Can remember "Nora" while holding stale policy fact in context.

Nora refund=30 stale

Vector stores, session databases, core memory systems. Specialized for conversation continuity. Not temporal knowledge bases unless you add versioning and time-travel queries on top. Pattern names (Zep-pattern, mem0-pattern) are architectural strategies, not SDK implementations.

Fig. 3 Temporal consistency failure modes Update mechanisms and degradation patterns

Some stores expire the old fact. Some only add. Some wait until overnight job, PR merge, or a person clicks approve.

Fig. 4 Refund window after the Slack signal Acme, authored timeline, Day 14, current truth

a Zep-pattern (Graphiti). Expiry on the graph; dashed record kept for as-of.

30 14 answer

Speak returns 14.

b mem0-pattern. ADD-only chips; search may rank the older fact.

30 14 stale search

Speak returns 30 stale.

Gold. At this clock the refund window is 14 days.

Fig. 5 Architecture update mechanisms Comparison of temporal handling strategies

a Zep-pattern. Graph with edge expiry. Old edge dashed, kept for as-of queries. New edge solid.

Acme 30 days [T₀, T₁₄) 14 days [T₁₄, now]

Point-in-time at T₁₄ returns 14. Historical at T₇ returns 30.

b mem0-pattern. Append-only vectors. Both facts persist. Search ranks by semantic similarity, not temporal validity.

refund: 30 t=T₀ refund: 14 t=T₁₄ ranked higher

Semantic search may return 30 stale. No temporal semantics.

Zep-pattern dashes the old edge, keeps it for as-of, answers 14 now. mem0-pattern adds a chip. Search can still hand you 30.

Methods

I Scope

The simulation uses authored signal timelines scored against a gold temporal reference (no live APIs, no LLM calls, no embeddings retrieval).

II Test

The test is simple: after a fact changes, does the architecture return the correct value for current queries and historical queries.