{"slug": "temporalstore-a-disruptive-open-source-engine-managing-your-llm-memory", "title": "TemporalStore: A disruptive open-source engine managing your LLM memory", "summary": "MatrixArk AI released TemporalStore, an open-source (Apache-2.0) Rust-native engine that manages LLM memory by storing compact, source-backed ContextPacks instead of replaying full transcripts, claiming to answer every question better while sending a tiny fraction of the tokens on a real agent history. The engine, which runs from a single Docker command and never calls an LLM or embedding model, persists memory across sessions, devices, agents, and teams, and is available on GitHub.", "body_md": "**TemporalStore** replaces that with a small, ranked, source-backed\n\n**ContextPack**: on a real agent history it answered every question better while sending a tiny fraction of the tokens. And because memory lives in the engine — not the prompt — it persists\n\n**across sessions, devices, agents, and your whole team**, something point-in-time retrieval over one transcript can't do. Open source, self-hostable. Come build it with us →\n\n[github.com/matrixarkai/TemporalStore](https://github.com/matrixarkai/TemporalStore).\n\n## The usual approach: append everything, every turn\n\nThe typical way to give an agent memory is the simplest one: on each new turn, append\n*all* of the prior context — the earlier prompts *and* the model's own intermittent output —\nback into the next input window, and send it again.\n\nIt works, so it ships. But it has two quiet problems.\n\n**Most of what you re-send is noise.** A lot of that appended history — especially the\n*intermittent output*: tool results, logs, stack traces, file dumps — was useful for a single step\nand then just sits in the window, re-sent every turn, diluting the signal the model actually needs now.\nYou pay for it on every call, and it crowds out the few lines that matter.\n\n**And nothing is learned.** It's all trapped in one session — there's no cross-session\nmemory, and no long-term profile that gets *better* as the history deepens. The agent never\naccumulates what it figured out about the user, the project, or the decisions already made; when the\nwindow rolls or the session ends, it starts from zero.\n\nSo you pay more (re-sending a growing, noisy transcript) and remember less (nothing survives the session). That's the trap.\n\n## The \"solution\" that becomes its own stack\n\nSo you add retrieval. Reasonable instinct. But watch what \"agent memory\" quietly turns into in production:\n\n- a\n**vector database** to store, version, and semantically search the embeddings, - a\n**summarization / extraction pipeline** to compress old turns into something retrievable, - and a\n**memory service** to glue it together, decide scope, and rank — usually a bespoke one.\n\nThree systems, and you're *still* replaying transcripts on the side. Three things to run, monitor,\nand keep consistent — all to answer one small question on every turn: *what does this agent actually\nneed in front of it right now?*\n\nThe bet behind TemporalStore is that agent memory is one temporal problem — and deserves one temporal engine, not a stitched-together stack.\n\nIt's open source (Apache-2.0), Rust-native, runs from a single Docker command, and ships with reproducible benchmarks instead of adjectives. Here's how it works, and why the numbers land.\n\n## The core idea: send a ContextPack, not a transcript\n\nThe design draws one clean line. Your model reasons and extracts; the engine remembers and serves.\n\n```\n# the flow — you own the model, TemporalStore owns the memory\nraw query / event / resource + hints\n  → extract intent, time, filters, entities   (your runtime, or MatrixArk)\n  → store compact serving records             (TemporalStore)\n  → retrieve a token-budgeted ContextPack     (TemporalStore)\n  → final LLM  =  local context  +  ContextPack\n  → the answer becomes tomorrow's memory\n```\n\nNotice what TemporalStore **doesn't** do: it never calls an LLM or an embedding model.\nYour harness — or a managed runtime like **MatrixArk**\n([matrixark.ai](https://matrixark.ai)) that sits on top — produces the vectors and structured\nintent. TemporalStore stores them and does the fast, bounded work at serving time.\n\nThat work produces the whole point of the system: a compact, **source-backed**\n`ContextPack`\n\n. Not a transcript — the few hundred tokens that actually matter for *this*\nquery, each traceable to the event that produced it.\n\n**And it denoises.** Remember all that re-sent intermittent output? TemporalStore ingests\nit as compact records — the tool call kept as a short marker, the bulky result head-truncated or\nsummarized — so the pack carries the *fact* the tool produced, not the noisy blob. Less noise in the\nwindow is itself better answers: the model isn't rummaging through stale logs to find the one line that\nmattered.\n\n## What you get, in one line each\n\nThe payoff up front — the mechanism behind each one is the rest of this piece:\n\n**Fewer tokens at equal-or-better quality**— a bounded ContextPack instead of a transcript that grows every turn.** Better answers, less hallucination**— time-valid memory with replayable, source-backed citations.** Low serving latency across millions of entities**— work bounded by the filtered candidate set, not the corpus.** Exact recall, no vector DB**— a controlled candidate set scored exactly; ANN's lossiness never enters the picture.** Team-wide memory**— cross-session, cross-device, cross-agent, and auditable by construction.** One engine, self-hosted**— Apache-2.0, one Docker command, no LSM write-amp on the append path.\n\n## Why a small pack beats \"replay the newest N tokens\"\n\nThis is the counterintuitive part, so let's prove it instead of asserting it.\n\nTake a **real** working set: a developer's full local coding history, tool calls included —\n**12,384 events, 97 sessions, ~1.7M tokens**. Ask six real questions about it. Run two arms\nthrough the *same* reader model and the *same* judge:\n\n**Replay**— feed the full local history, newest-first, up to the model's window.** Managed**— retrieve a token-budgeted`ContextPack`\n\n.\n\n| Metric | Full replay | TemporalStore pack | Result |\n|---|---|---|---|\n| Tokens the model works from | 1,698,940 | ~1,333 | 99.9% fewer |\n| Answer quality (judge, 0–10) | 6.59 | 8.30 | +1.71 |\n| Questions won or tied | — | 6 / 6 | every one |\n\nNow the *why*, which is more interesting than the headline.\n\n**The pack wins by the widest margin on the questions whose answers live in old history** —\n`q_storage`\n\n10.0 vs 6.05, `q_parity`\n\n8.05 vs 5.25. It wins by the smallest margin\nwhen the newest messages happened to already be on-topic.\n\nThat gradient *is* the mechanism, made visible: recency-truncated replay literally cannot see the\nold-but-relevant facts that ranked retrieval surfaces. **You pay for 1.7M tokens and still get the\nworse answer.**\n\n**And it holds up on the standard memory benchmarks.** On **LoCoMo** and\n**LongMemEval_s** — the two public long-term-memory suites the field measures agent recall\nagainst — TemporalStore's tree-plus-index retrieval lands **hit@k 0.995–1.00**. And in a\nhead-to-head on one shared open-source stack (a `qwen2.5:7b`\n\nreader, MiniLM embeddings,\nClaude-judged), it **ties** an OpenViking-style baseline — a reimplementation of\n[VikingMem](https://arxiv.org/abs/2605.29640), the memory system that reported state-of-the-art\nin its own paper — on short LoCoMo chats (~83–84%) and\n**wins long-horizon LongMemEval outright — 98% vs 66%** answer accuracy. So the token\nsavings above aren't bought with worse recall: the pack is small *and* it finds — and answers —\nthe right evidence.\n\n## Memory that's shared — not stuck in a session\n\nHere's the differentiator that matters most for real teams, and it's easy to miss under the token math.\n\nA transcript is trapped in one session. The moment the window rolls or the tab closes, it's gone. That's\nthe true ceiling on agent memory — not how much you can stuff into one prompt, but whether anything survives\n*between* prompts, *between* agents, *between* people.\n\nBecause TemporalStore keeps memory in the engine — ingested once, indexed by scope\n(`tenant → user → session → agent → resource`\n\n) — recall isn't bound to the current thread. An\nagent can remember what *another* agent learned yesterday, what the user decided on a\n*different device*, what the *team* agreed last month. And because every recalled fact is\ntimestamped and traceable to its source event, shared memory stays **auditable** — a citation,\nnot a rumor.\n\nCross-session, cross-device, cross-agent, cross-teammate — by construction. That's the memory a single-transcript retriever structurally cannot give you.\n\n## The serving innovation: a database's serving path, aimed at memory\n\nMost \"agent memory\" libraries are a thin wrapper over a vector index. TemporalStore is built like a database — and that shows most in the serving path. Three roles, disaggregated:\n\n**Proxy**— the front door: routing, request batching, backpressure.** Metaserver**— placement, leases, the shard map. It decides*where*data lives; it's off the hot read path.**Datanodes**— the workers: a write-ahead log for durability, the model executors, the in-memory indexes that answer reads.\n\n**Retrieval is not a brute-force vector scan.** Context is a tree — tenant → user → session\n→ resource → entity. A query walks it layer by layer, using compact **secondary indexes** to\nprefilter *before* reading any timeline. Filters compose by **intersecting posting lists**\n— status ∩ project ∩ time-bucket — so a query touches a bounded set of events, not the whole corpus. Only\nthen does it score, apply temporal decay, and pack to budget.\n\nThe payoff: **latency stays low even across millions of entities**, because the work per\nquery scales with the *filtered* set, not the dataset. ContextPack retrieval runs\n**~17 ms p95** at a 1.2k-token budget.\n\n## The storage innovation: append-structured and temporal\n\nUnderneath is a storage engine built around one fact: **memory is temporal.** Data arrives\nin time order, is queried by time, and cools with age. That shapes every layer.\n\n**Append-structured.** Writes append; nothing mutates in place, and the engine reloads\ncrash-safe from its own write-ahead log. When the segmented log once re-parsed itself on every append (an\nO(n²) trap — append #200 took 100+ ms), a per-node cursor made it O(1): **109 ms →\n2.2 ms**, with the on-disk format byte-identical so live stores reload with zero migration.\n\n**Real tiering — eviction and promotion.** Hot data sits in memory; as the working\nset outgrows the budget it's evicted down through cache to SSD and shared storage. The part most systems\nget wrong:\n\n**cold data is promoted back into memory on read.** A multi-user harness proves it — a deliberately tiny memory budget to force eviction, then cold reads to force promotion:\n\n**256k reads, zero mismatches**, partition isolation intact, up to 81 users and 187k writes.\n\n**Compute/storage separation.** The same code runs three ways — **local**\n(one node), **Raft-replicated**, or **shared-storage** — so you start on a laptop\nand scale to a disaggregated cluster where compute and storage grow independently, atop two self-contained\nApache-2.0 libraries: [ MatrixCache](https://github.com/matrixarkai/MatrixCache)\n(caching) and\n\n[(replication). For the shared-storage tier at scale, stateless datanodes read and write one durable object store —](https://github.com/matrixarkai/MatrixRaft)\n\n**MatrixRaft****MatrixObject**, the enterprise object store engineered for extreme-performance shared storage — so compute can scale for traffic spikes without copying every shard to every node.\n\n## Why no vector database\n\nRAG usually runs on a vector DB doing *approximate* nearest-neighbor (ANN) search over a giant\nflat pile of embeddings — trading recall for speed, because scoring every vector exactly is too expensive.\nTemporalStore never gets there. Its **layered virtual file system** and compact\n**secondary indexes** filter most candidates out first — by scope, type, entity, and time — so\nby the time we rank, the set is small and we score it **exactly, with no ANN loss** (that's the\nhit@k 0.995–1.00 above). That same scoped tree doubles as a **virtual file system** for\n*resources, skills, and memory* — one time-aware namespace instead of a separate store for each — so\nit's also one fewer system to run and keep in sync.\n\n## Why no RocksDB (no LSM)\n\nTemporal memory is *append-heavy* — you're constantly writing new timestamp-keyed events — which\nis exactly what an LSM like RocksDB handles worst: compaction keeps rewriting data it already wrote\n(**write amplification**), with tail-latency spikes and stop-the-world pauses. TemporalStore's KV is\nshaped for it: a key's *value* is a run of **timestamp-keyed values appended in order**,\nso an event is an append onto an existing value — not a flood of new keys to merge and re-sort. The result:\n**far less write amplification than RocksDB**, no compaction, no pauses.\n\n[temporalstore.ai](https://temporalstore.ai)and the\n\n[Tech & Infra deep dive](https://temporalstore.ai/temporalstore.html), with reproducible methodology at\n\n[temporalstore.ai/benchmarks.html](https://temporalstore.ai/benchmarks.html).\n\n## Try it in two minutes\n\nNo Rust toolchain on your host — it builds inside the image:\n\n```\ngit clone https://github.com/matrixarkai/TemporalStore.git\ncd TemporalStore\ndocker compose -f docker-compose.single-node.yml up --build\n```\n\nYou get a metaserver on `127.0.0.1:17101`\n\nand a datanode on `:17102`\n\n. Whole\ndependency list: Docker and a clone.\n\nPrototyping one session with a few docs? A plain vector index is fine — TemporalStore earns its place when memory has to persist across sessions, agents, and a team, stay sharp at millions of events, and stop you re-sending a growing transcript every turn.\n\n## Two invitations\n\n### 🛠️ If you build on temporal data — come build with us.\n\nWhether you want to serve your own **temporal use cases** on TemporalStore, layer a\n**context system** on top of it, or dig into the **innovative Rust core** —\nRaft replication, the multi-layer cache, and the append-structured storage engine — there's real,\nopen work here. Apache-2.0, and small enough to actually get into.\n\n[⭐ Star & build on GitHub](https://github.com/matrixarkai/TemporalStore)\n\n### 📉 If you run agents in production — cut this line-item.\n\nA bounded, ranked **ContextPack** cuts context cost sharply *while raising answer\nquality*, and folds a stack of separate memory services into one self-hosted engine. It also gives\nagents **team-wide, cross-session memory** — every recalled fact traceable to its source,\nand no data ever leaves your boundary.\n\n[Pilot it on your workload →](https://temporalstore.ai)", "url": "https://wpnews.pro/news/temporalstore-a-disruptive-open-source-engine-managing-your-llm-memory", "canonical_source": "https://temporalstore.ai/blog-context-management.html", "published_at": "2026-08-15 20:51:41+00:00", "updated_at": "2026-08-15 21:10:48.234800+00:00", "lang": "en", "topics": ["large-language-models", "ai-infrastructure", "ai-tools", "ai-agents"], "entities": ["MatrixArk AI", "TemporalStore", "MatrixArk"], "alternates": {"html": "https://wpnews.pro/news/temporalstore-a-disruptive-open-source-engine-managing-your-llm-memory", "markdown": "https://wpnews.pro/news/temporalstore-a-disruptive-open-source-engine-managing-your-llm-memory.md", "text": "https://wpnews.pro/news/temporalstore-a-disruptive-open-source-engine-managing-your-llm-memory.txt", "jsonld": "https://wpnews.pro/news/temporalstore-a-disruptive-open-source-engine-managing-your-llm-memory.jsonld"}}