Use cases
Start with context management, then apply the same store to temporal features.
Context Management is the flagship use case: serving compact, replayable LLM context from temporal memory. Ranking, risk, ads, and fraud use the same engine through sequence, aggregate, and control-state primitives.
Agent and enterprise LLM systems need short-term and long-term team memory across sessions, agents, devices, tools, evidence, policies, and summaries.
Long sequences, aggregates, counters, and distinct state are the lower-level temporal data models used by context, ranking, risk, ads, and fraud.
One durable store handles memory, feature serving, replay, and safety state — and data moves automatically across memory, SSD, and shared storage, so hot state serves from RAM while everything stays persisted. It replaces the usual web of caches, stream jobs, and custom services.
Flagship use case
LLM context management as temporal storage plus serving.
A coding, support, research, or enterprise agent creates a temporal stream: goals, files, tools, retrieved evidence, decisions, user preferences, device context, and policy state. TemporalStore stores that stream as queryable short-term and long-term memory across sessions, agents, and devices, then serves only the right slice into the next model call.
Store decisions, tool traces, artifacts, preferences, and evidence as short-term working memory and long-term team memory instead of losing them when the prompt rolls over.
Open Context Management Token savings Serve fewer, better tokensBuild budget-bounded ContextPacks that select recent, source-backed, and summarized memory rather than dumping the whole transcript.
See benchmarks Serving layer Make context a system problemPersistent by design, memory-first for serving: data moves automatically across memory, SSD, and shared storage, with WAL replay and compute/storage separation for very large concurrent reads and writes.
Open Tech & InfraContext workflow
Write everything, serve only what matters now.
Capture events
Messages, tool calls, retrieved evidence, file edits, user corrections, and policy outcomes.
Attach time and scope
Key memory by session, team, project, user, source, and validity window.
Compress naturally
Keep raw history, summaries, counters, and preference deltas together as temporal state.
Build ContextPack
Filter, rank, and assemble a token-bounded slice for the next LLM request.
Replay and audit
Recover what the model knew at decision time and debug long-running work.
pack = store.build_context(
session_id="sess-4817",
now=turn_started_at,
budget_tokens=2048,
include=["messages", "tool_traces", "summaries", "preferences"],
window="24h",
)
prompt = render_system_context(pack)Additional use cases
The same engine serves temporal features beyond LLM context.
These are important, but they are secondary to the flagship context story. They show why TemporalStore is a general temporal serving engine, not a one-off memory component.
Serve recent ordered behavior — tool traces, viewed items, searches, clicks, session actions — as bounded time-window reads that seek to the window, never scan the whole history.
Open Long Sequence Risk and operations Aggregated FeatureCompute exact sums, counts, min/max, and grouped filters over windows on read — fresh fraud, marketplace-trust, and campaign-spend features with no Flink/Spark pre-aggregation pipeline.
Open Aggregates Safety and limits Control StateFrequency caps, velocity counters, distinct fan-out, cooldowns, and policy state on the serving path — durable across restarts and idempotent, so retries never double-count.
Open Control StateHow to choose
Start from the question you ask at read time.
Every workload keys state by an entity — a session, a user, a device, a card — and asks one temporal question online. The shape of that question tells you the model.
Four questions cover almost everything teams build on temporal state:
- “What has this agent seen, and what belongs in the prompt now?” → Context Management. Replayable memory: messages, tool traces, retrieval evidence, and summaries assembled into a compact ContextPack.
- “What is the recent ordered history for this entity?” → Long Sequence Feature. Tail reads and windowed slices over a long behavior sequence, for rankers and investigation tools.
- “What is the sum / min / max / count over a time window?” → Aggregated Feature. Filtered, grouped rollups for risk and recsys features.
- “How many, or how many distinct, in the last N minutes?” → Control State. Counters and distinct sets for frequency caps, velocity, and fraud.
One store answers all four, so an entity's context and its safety counters live on the same read path instead of four separate systems.
Pick by the question, not the storage. All four resolve on one temporal read path.
Worked examples
One store, many temporal questions.
The same engine, keyed differently, answers agent, ranking, risk, ads, and fraud questions online.
| Use case | Entity key | Model | Online question |
|---|---|---|---|
| Agent context | session_id | Context Management | What tool calls, summaries, and preference deltas should be in the prompt now? |
| Recommendation ranking | user_id | Long Sequence Feature | What recent product, search, or content sequence should the ranker see? |
| Failed-login risk | device_id | Aggregated Feature | How many failed logins by country and method in the last 30 minutes? |
| Ads frequency cap | campaign_id + user_id | Control State (counter) | How many impressions in the last hour, day, or campaign window? |
| Fraud velocity | user_id | Control State (counter) | How many purchases happened in the last 5 minutes? |
| Card-testing detection | card_id | Control State (distinct) | How many unique merchants did this card touch in the last 24 hours? |
Proof for the flagship use case
How TemporalStore compares to other memory systems.
This section belongs after the use-case map: it is evidence for the context-management story, not a separate product direction. We benchmark against the strongest agent-memory baselines because that is the bar a context-serving engine has to clear.
| System | Approach | Temporal & replay | One service | Retrieval |
|---|---|---|---|---|
| TemporalStore | Append-structured temporal store; Context model | Native event-time + replay | Yes — memory, retrieval, counters, replay in one engine | Filter-first temporal; optional vector recall |
| SOTA agent-memory baselines | Event/entity memory, L0/L1/L2 layers, temporal compression | Temporal layers | Memory-focused | Hierarchy + recall |
| Mem0 | Developer-friendly add/search, scoped memories | Limited | Needs a separate vector store | Vector-first |
| Zep / Graphiti | Bi-temporal knowledge-graph memory | Bi-temporal graph | Graph + retrieval | Hybrid semantic / keyword / graph |
| MemOS / Memori | OS- and filesystem-style memory | File-like | Memory-focused | Path + recall |
Pros and cons of the TemporalStore approach
Where it wins: one service instead of vector DB + cache + feature store + queue; append-structured, event-time storage with replayable, auditable decisions and no LSM compaction write-amplification on temporal appends; filter-first retrieval that narrows to a controlled candidate set and scores it exactly — no lossy approximate-nearest-neighbor stage — while respecting time validity and supersession, so fewer stale or out-of-scope chunks reach the prompt; large token savings from managed context packs; low latency at scale via memory-first serving with automatic memory–SSD–shared-storage tiering; and open source with an enterprise path to disaggregated, five-nines storage.
Honest trade-offs: for pure fuzzy semantic recall a vector-first system can surface loosely-related text that filter-first traversal skips (TemporalStore treats vector recall as an optional add-on); the leading hierarchical-memory systems are mature; and TemporalStore is a younger open-source project still growing its ecosystem.
Head-to-head benchmark results vs SOTA agent-memory baselines
On a shared open-source harness — the same reader model and embeddings for both systems, scored by an LLM judge — TemporalStore matches or beats the strongest baseline: overall 88% vs 78%, driven by long-horizon memory (LongMemEval 98% vs 66%), while LOCOMO is a tie (~83–84%). Retrieval hit@k is comparable-to-better (LongMemEval 1.00 vs 0.88), and managed context packs cut prompt tokens sharply at equal answer quality.
See the full LOCOMO + LongMemEval report, the 3-arm token-quota study, and the published landscape →
Keep reading