Fewer prompt tokens
TemporalStore compacts long histories into fresh, source-backed ContextPacks, so agents stop shipping repeated transcript noise and stale retrievals to every model call.
Open source · Rust · Apache-2.0
Context management is a serving plus dedicated storage problem.
TemporalStore is the open-source, Rust-native serving engine and dedicated temporal store for LLM context. It handles real-time ingest, token-budgeted retrieval, freshness, replay, memory-first tiering, temporal compression, high-concurrency reads and writes, and O(1) control in one durable engine. Context is the flagship data model; the same store serves real online state in cloud or on-premise deployments.
Context is served
In one place
01Fresh memoryWhat was said, done, approved, or superseded over time
02Serving pathProxy, metaserver, datanodes, WAL, indexes, and cache fill
03Scale evidenceLarge concurrent read/write paths with shared-store benchmarks
04Temporal modelsContext, sequences, aggregates, counters, distinct sets, and profiles
Why it wins
Why agent context needs a serving engine and a temporal store.
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 treats context management as a serving plus dedicated storage problem: one temporal engine remembers what happened, when, and why, then serves 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 memory-first, multi-layer architecture, serving latency stays extremely low even across millions of entities. Hot context stays in memory, warm state moves through PMem and SSD, and cold replay history lands in shared storage. 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 on premise, run in your cloud, or scale the same engine to disaggregated shared storage and five-nines when you need it.
Better answer quality
Time windows, supersession, stale-context blocking, and replayable citations keep the model grounded in what is current, permitted, and actually relevant.
Memory-first temporal storage
Context is stored as model-aware temporal state, not opaque chunks. Hot state is served from memory first, then automatically moves across PMem, SSD, and shared storage as it cools.
Compute/storage separation
Local, Raft, and shared-store modes let deployments move from a self-hosted node to disaggregated storage where stateless datanodes scale independently.
Extreme serving latency
Memory indexes, PMem/SSD cache fill, WAL-first durability, and append-structured blocks are built for large agent workloads with simultaneous ingest, retrieval, and replay.
Less maintenance
One engine replaces a patchwork of vector DB, cache, feature store, queue, summarizer, replay store, and repair jobs, while remaining open source and self-hostable.
Tech & infrastructure
The homepage version: enough architecture to know it is real.
TemporalStore is not a prompt trick or a sidecar vector index. It is a serving engine with routing, WAL durability, model-aware datanodes, a memory-first multi-layer cache, and automatic hot-to-cold context movement across memory, PMem, SSD, and shared storage. The full Tech & Infra page now carries the detailed write path, cache-fill path, storage layout, replication modes, and deployment examples.
Serving path
Proxy, metaserver, datanodes
How writes route to a shard, persist in the WAL, update indexes, and replicate.
Storage engine
Memory, PMem, SSD, shared storage
How hot data stays close to compute while cold history remains queryable over time.
Evidence
AWS shared-store benchmark
MatrixObject vs EFS results for concurrent writes, async flushes, and replica health.
The full page is intentionally more technical: storage files, page indexes, cache admission, Raft vs shared-store replication, sync vs async durability, and local/distributed deployment. Open the Tech & Infra deep dive →
Design choices — TL;DR
No separate vector DB. Far lower 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.
Much lower write amplification than RocksDB
An append-structured block store packs values and appends bands instead of rewriting LSM SSTables, so high-write temporal workloads see far lower write amplification than RocksDB — and sidestep its compaction stalls. It is reduced, not zero: the WAL, block, and index still write, and background GC reclaims obsolete regions — but there is no repeated LSM re-write of live data. 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.
Open source
Apache-2.0, self-hostable, no lock-in.
The serving core and its libraries are open source, so you can run the whole context engine yourself.
TemporalStore is released under Apache-2.0 by MatrixArkAI. Self-host with the open-source serving core plus the MatrixCache and MatrixRaft libraries, bring your own OSS models (Ollama, no API keys required), and add the enterprise object/KV/DB backends only if and when you need disaggregated, five-nines deployments.
TemporalStore
The temporal context serving engine
Proxy, metaserver, and datanodes serving replayable Context over a WAL.
MatrixCache
The multi-layer cache library
L1 memory + L2 SSD cache with admission and eviction for hot temporal reads.
MatrixRaft
The Rust Raft library
Consensus and replicated WAL for high-availability datanode replicas.
Get involved: open an issue or discussion on GitHub, or follow the install guide to run it yourself.