Flagship use case: Context
Replayable context memory for AI agents and coding systems.
TemporalStore.AI focuses on the Context data model: session memory, tool-call history, retrieval evidence, summaries, safety counters, and decision replay. Other temporal workloads prove the same store can serve real online state.
Why it wins
Why manage agent context in TemporalStore.
An AI agent is only as good as the context it is given. The usual answer — stitch a vector database to a cache to a feature store to a queue, then replay whole histories into every prompt — is expensive to run, hard to keep in sync, and impossible to audit. TemporalStore replaces that stack with one temporal engine that remembers what happened, when, and why, then hands the model a compact, source-backed ContextPack instead of a transcript.
The payoff is concrete. Managed, de-duplicated packs send only fresh, relevant evidence, so you get Fewer tokens at equal answer quality — often a large reduction in prompt tokens. Time-valid memory with stale-context blocking and replayable citations means Better answers and less hallucination. And because retrieval is bounded temporal reads over a multi-layer cache, latency stays low even across millions of entities. See benchmarks.
Beyond speed and quality, TemporalStore is one service instead of four: memory, retrieval, summaries, safety counters, and replay live in a single store. Every decision is replayable and auditable — reconstruct the exact context behind any answer for debugging, evaluation, or compliance. And it is open source: self-host the core, or scale the same engine to disaggregated shared storage and five-nines when you need it.
Tech & infrastructure
The Context story is backed by real serving infrastructure.
The infrastructure is the product: context management is only as good as the store underneath it. Clients talk to an open-source serving core — a proxy, a metaserver, and datanodes that run model-aware executors over a WAL. The core leans on two open-source libraries, MatrixCache and MatrixRaft, and moves Context data hot to cold across memory, SSD, and a shared store. And history is compressed natively — rolling L0/L1 summaries fold old detail into compact, still-replayable digests, so long timelines stay small and cheap to serve. Enterprise object/KV/DB backends plug in underneath for disaggregated, five-nines deployments.
Serving core and dependency libraries (MatrixCache, MatrixRaft) are open source. MatrixObject, MatrixKV, and MatrixDB are enterprise storage backends for shared-storage and disaggregated deployments.
How data flows and replicates
A write is routed by key to its shard's primary datanode, appended to the WAL, applied in memory, then replicated — either to full Raft replicas, or to one shared durable store that stateless datanodes read.
Reads take the same route — Client → Proxy → primary or replica datanode → served from memory / SSD cache, with WAL replay filling cold state. Full data-flow & replication in Tech & Infra →
The context workflow
Every write and every query follows the same six-step path — from raw events to a prompt-ready pack, with feedback written back as new memory.
Write events
Agents send messages, tool calls, docs, approvals, and answers through one context API. Writes append to the WAL and hot memory tier; batched fsync amortizes durability.
Structure the signal
Extract entities, event type, timestamps, validity, permissions, and source refs. Text is embedded (MiniLM-class) for semantic recall; scope hashes group related context.
ContextNodes & indexes
Build ContextNodes, ContextEvents, secondary indexes, and L0/L1 summaries. Dirty-summary markers drive incremental rollups instead of full recompute.
Candidate generation
A raw query becomes intent + time window + filters. Filter-first tree traversal narrows scope hashes; optional vector recall adds semantic candidates; bounded reads cap fan-out.
Relevance + freshness
Candidates are scored by relevance, recency, source trust, and dedup; stale or superseded memories are blocked. A token budget (elbow near 4096) selects the final set.
ContextPack + feedback
Return a prompt-ready ContextPack with citations and a replay id. Accepted answers, corrections, and outcomes are written back as new memory.
One API for the write path (ingest → extract → compile) and the read path (retrieve → rank → pack). Full infrastructure deep dive.
Design choices — TL;DR
No separate vector DB. No write amplification.
No separate vector database
Context is retrieved filter-first over a temporal tree using scope hashes and time windows; semantic vector recall is an optional add-on, not the primary index. For most agent-memory queries you avoid running, syncing, and paying for a standalone vector store.
No RocksDB-style write amplification
An append-structured block store packs values and appends bands instead of rewriting LSM SSTables, so high-write temporal workloads avoid RocksDB-style write amplification and compaction stalls. Details in the Tech & Infra deep dive.
Data models
Context first, with supporting temporal primitives.
The flagship model is Context Management — agent memory, tool events, retrieval traces, summaries, replay, and safety counters. The same engine also serves a family of supporting temporal models that prove it can carry real online state:
- Long Sequence Feature — ordered behavior history for rankers, agents, and investigation tools.
- Aggregated Feature — filtered sum, min, max, count, and grouped rollups over time windows.
- Control State — frequency caps, velocity checks, and distinct sets for throttles and safety.
- Profile — latest entity facts colocated with temporal history.
Start here