Open Source TemporalStore
Start with one store: TemporalStore for LLM memory.
Choose this path when the core problem is memory over time: what happened, what changed, what is fresh, what should be replayed, and what context should enter the next prompt.
Why this is unique
Most open-source LLM memory starts as summaries, embeddings, or framework callbacks. TemporalStore is different: it treats memory as temporal serving data. The store knows order, freshness, replay, counters, windows, and low-latency reads before the prompt is assembled. That makes one open-source store useful for real context engineering, not only demos.
Choose this when you need
Open-source TemporalStore is useful by itself. It gives agents, copilots, prompt builders, and eval pipelines a durable temporal memory layer without asking teams to adopt the full MatrixArk platform on day one.
Session timelines
User turns, tool calls, retrieved sources, agent actions, retries, and state transitions ordered by time.
Prompt replay
Reconstruct the exact context pack used by a model call, including memory deltas, source versions, and prompt sections.
Freshness and windows
Serve recent events, windowed counters, stale-memory warnings, source freshness, and time-valid records at request time.
Low-latency context reads
Keep timeline, filter, sequence, and counter queries fast enough to participate in prompt assembly, not only offline debugging.
Memory governance
Mark memories as current, stale, superseded, low-confidence, blocked, or replayable before they enter the prompt.
Cache eligibility signals
Tell LMCache-style systems which prompt sections are stable and which temporal memories or sources must be refreshed.
What you can ship first
| Use case | TemporalStore-only implementation | Why it is enough |
|---|---|---|
| Support memory | Store customer timelines, prior replies, tool failures, escalations, open promises, and stale-memory flags. | The main problem is temporal memory and replay, not a separate current-value database. |
| Agent time travel | Persist user turns, retrieved context, prompt sections, tool outputs, and model decisions as ordered events. | Debugging needs ordered history and exact prompt reconstruction. |
| Prompt evals | Run new prompts or models against historical context packs assembled from the same timeline data. | Temporal replay creates realistic eval cases without inventing synthetic context. |
| Policy-time answers | Read facts, document references, and source freshness valid at a requested time. | The critical primitive is time-valid context selection. |
| Runtime reuse signals | Emit cache eligibility, invalidation, and source-version signals from temporal events. | TemporalStore can decide what changed even when LMCache handles model-runtime reuse. |
Where this stops
TemporalStore alone is the best path when the hardest problem is time-aware context and memory. The full MatrixArk stack starts to matter when the company also needs serverless hot state, Redis-compatible integration, strongly consistent truth, permissions, leases, approvals, and committed workflow state.
| Question | Use open-source TemporalStore alone | Use the three-product stack |
|---|---|---|
| Primary need | Temporal memory, replay, freshness, low-latency context reads. | Temporal memory plus serverless hot KV and committed truth. |
| Adoption model | Developer starts with one Rust store and one temporal context API. | Customer uses MatrixArk as a platform that routes work to the right engine. |
| Hot profiles and cache metadata | Can be modeled as temporal context if small and time-oriented. | Move to MatrixDB when Redis-compatible hot state, scans, exports, and multi-tenant serverless KV matter. |
| Permissions and approvals | Can be recorded as events for replay and audit. | Move to MatrixKV when the product needs one strongly consistent committed answer. |
| Best buyer | Builders, OSS users, early-stage vertical AI teams, and internal agent teams. | Vertical AI companies and enterprise platforms that need production state boundaries. |
The minimal architecture
task, user, entity Context builder
budget, rank, compress LLM runtime
answer, tool call, action
timeline, memory, replay, freshness, counters VectorDB / S3
optional retrieval and raw source objects LMCache-style runtime
optional prefix and KV-cache reuse
The open-source path keeps the thesis focused: one temporal store manages the time-aware memory and context timeline first. VectorDB and S3 can stay external for retrieval and raw objects; TemporalStore decides which temporal facts are fresh enough to use.