Open-source path
Start with one store: TemporalStore for LLM memory.
Choose this path when the hardest problem is memory over time — what happened, what changed, what is still fresh, what should be replayed, and what context should enter the next prompt. Open-source TemporalStore is a durable temporal memory layer for agents, copilots, and eval pipelines without adopting a full platform on day one.
Why this is different
Memory as temporal serving data, not a bag of summaries.
Most open-source LLM memory starts life as summaries, embeddings, or framework callbacks. TemporalStore treats memory as temporal serving data. The store knows order, freshness, replay, windows, and low-latency reads before the prompt is assembled. That makes one open-source store useful for real context engineering, not only demos.
Context is more than a search result. It is a timeline, a freshness signal, and a record of what already happened. A vector hit tells you a chunk is similar; it cannot tell you whether the fact is still true, whether a promise is still open, or what the agent already tried. TemporalStore answers those questions in the request path.
What you get 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 a model call used, including memory deltas and source versions.
- Freshness and windows — serve recent events, windowed counters, and time-valid records at request time.
- Low-latency context reads — timeline, filter, sequence, and counter queries fast enough to join prompt assembly, not just offline debugging.
- Memory governance — mark memories current, stale, superseded, low-confidence, blocked, or replayable before they enter the prompt.
What you can ship first
Real context products on TemporalStore alone.
Each of these is fundamentally a temporal-memory problem. You do not need a separate current-value database, a graph engine, or a vector store to start.
| Context 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 problem is temporal memory and replay, not a separate truth database. |
| Agent time travel | Persist user turns, retrieved context, prompt sections, tool outputs, and 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 and source-version signals from temporal events for LMCache-style reuse. | TemporalStore can decide what changed even when a runtime cache handles model-level reuse. |
The MVP surface
A small context API, not a general database.
The open-source path starts with a context API rather than a general storage surface. Customer JSON can be flexible at ingestion, but the hot prompt path queries compiled nodes, events, indexes, and audits under strict limits.
Four record types
- Context nodes — canonical domain nodes with parent hashes, short summaries, status, and refs.
- Context events — timestamped facts with kind, status, confidence, importance, source refs, and compact attributes.
- Secondary indexes — declared equality-prefix indexes plus inclusive time ranges for serving-time filters.
- Context audit — selected refs, blocked refs, token budgets, query ids, and replayable request records.
Developers get simple operations — add, update, upsert, merge, forget — while TemporalStore translates each call into append-only events, latest-state updates, index maintenance, validity changes, summaries, and replay metadata.
get_context_pack({
raw_query: "Can we honor the refund we promised?",
scope: { account: "acme", agent: "agent_17" },
as_of: "now",
budget: { max_prompt_tokens: 1200, deadline_ms: 30 }
})
// TemporalStore serves, bounded and valid:
ContextPack {
latest: entitlement (current), refund_promise (open),
timeline: 2 recent replies in window,
stale: 1 superseded policy excluded,
replay_id: "cp_7c02aa",
tokens_used: 880
}The minimal architecture
One temporal store, external retrieval optional.
The open-source path keeps one thesis: a single temporal store owns time-aware memory and the context timeline first. A VectorDB and object store stay external for broad recall and raw objects; TemporalStore decides which temporal facts are fresh enough to use now.
Where this stops
When one store is enough — and when it is not.
TemporalStore alone is the best path when the hardest problem is time-aware context and memory. The full MatrixArk stack starts to matter when a production platform also needs serverless hot state, Redis-compatible integration, strongly consistent truth, permissions, leases, approvals, and committed workflow state alongside the timeline.
Start with the open-source engine and one temporal context API. Move to the platform when hot profiles, cache metadata, or committed truth outgrow what a temporal memory layer should carry — see the full-stack path and the state engine routing guide. The source lives at temporalstore.ai.
Keep reading