TemporalStore deep dive
Inside the context serving engine.
Modern agents need reliable prompt context inside the request path: session timelines, tool events, memory deltas, prompt replay, freshness counters, and long context sequences — filtered by time, source, and policy. TemporalStore is the time-aware engine that serves that context online, with durable state that stays replayable after the answer.
TemporalStore fills the gap between vector databases, logs, prompt templates, and caches: one online system for context state that changes fast and must be retrieved at prompt time. Agents repeatedly ask the same kinds of question — what did the user say recently, which tool already failed, which promise is still open, which memory was superseded, and what belongs in the next model call? Those need a serving layer that understands time, freshness, replay, and policy-aware assembly, not another blob store.
The failure mode it replaces is the scattered stack: prompts in one place, vector search for chunks, a cache for summaries, logs for tool traces, and application code doing permissions, freshness, and final stuffing. That works until every response needs session state, tool history, policy counters, source validity, and committed actions in one bundle.
What the engine owns for context
- Session timelines — user turns, tool calls, retrieval events, and source changes over time.
- Prompt replay — reconstruct what the agent knew, retrieved, filtered, and committed before each call.
- Freshness counters — stale memory, repeated failures, open commitments, and request-time validity.
- Long context sequences — recent ordered events served with limits, filters, and timestamps.
- Memory governance — keep superseded, unauthorized, or conflicting memories out of the prompt.
Architecture
A small serving vocabulary over a metaserver and shard-partitioned datanodes.
Applications address state by namespace, table, and key.
The engine handles typed updates, read policy, replica freshness, and shared-store recovery
behind that boundary.
Write and read workflow
Writes are typed context commands, not opaque blobs; reads are bounded entity queries, not table scans.
Write
A command arrives with namespace, table, key. The datanode validates model limits, updates typed state, and appends to the wal for replay.
Serve
Hot reads answer from memory-resident state; replicas become readable once freshness policy allows read fanout.
Recover
After movement or restart, a replica catches up from shared-store retained records and the durable wal, then re-enters serving.
append_context_rows(
namespace_name = "agent_workspace",
table_name = "session_timeline",
key = session_id,
rows = [{ timestamp, source, tool_name, confidence, visibility }]
)
query_context_rows(
key = session_id,
start_ts = now - 30m,
end_ts = now, # end-time inclusive
count = 100, # caps matching rows, not rows scanned
filters = [{ field: "source", op: Equal, value: "tool_call" }]
)The query targets one entity key and asks for a bounded model operation over retained state — not a full-table scan. That shape fits high-cardinality context, where many users, sessions, documents, and workflows update independently while each request touches one entity or a small set. Applications do not run a separate streaming job for every counter, filter, or window; the engine keeps typed state close to the request path and persists it through the configured storage mode.
Context-native data models
The right model depends on the context question the agent is asking.
| Context question | Entity key | Model | Example read |
|---|---|---|---|
| Recent tool activity | session_id | Sequence | Last 100 tool calls, filtered to failures. |
| Repeated-failure guard | session_id | Counter | How many times a step failed in the last hour. |
| Distinct sources touched | matter_id | Distinct | Unique documents referenced in the last day. |
| Open commitments | account_id | Selection | Promises still unfulfilled as of now. |
| Memory freshness | entity_id | Latest value | Newest valid fact, with its valid-from time. |
| Full agent context | session_id | Sequence + counters | Recent turns, retrieval feedback, and safety counters together. |
Why not just Redis or an LSM KV?
Redis-style systems are excellent for strings, hashes, and latest-value serving; the
enterprise MatrixDB backend covers Redis-compatible
hot state at scale. TemporalStore is different: it puts temporal semantics
inside the serving engine. A generic LSM KV can persist the same data, but hot,
update-heavy context still travels a generic path, so write amplification shows up in
several places at once — blob rewrites, cache updates, compaction, replay logs, and
downstream materialized tables. TemporalStore uses a purpose-built temporal layer for hot
typed state, the durable wal, retained records, multi-tier cache, shared-store
recovery, and replica-readable serving.
Not a GPU KV-cache
TemporalStore does not replace the transformer KV cache used by vLLM, SGLang, or LMCache-style systems — the runtime still owns tensor layout, prefix matching, and attention-cache APIs. The integration point is remote cache orchestration: LMCache reuses model prefixes, MatrixDB exposes hot cache metadata, and TemporalStore serves the fresh temporal context, policy counters, and timelines that decide what should be sent to the runtime in the first place. The engine is open source at temporalstore.ai; a Rust implementation is on GitHub.