Way fewer tokens per request
ContextPacks remove duplicated transcript text, stale facts, and irrelevant retrievals before prompt assembly. The model sees compact evidence instead of raw history, which turns directly into lower inference spend.
matrixark.ai
● Now open source TemporalStore is published — anyone can run itEnterprise LLM context management that cuts tokens and scales.
MatrixArk is the enterprise context-management platform behind the open-source TemporalStore, deployable in your cloud or on premise. It turns raw agent activity, documents, tool results, approvals, and answers into compact, time-aware ContextPacks, so production LLM systems send far fewer tokens, save real inference cost, improve answer quality, and keep replayable memory at enterprise scale.
Lower token spend, higher quality
POST /context/pack
{
"query": "Can we approve another GPU batch?",
"scope": "acme/infra/procurement",
"token_budget": 1800,
"quality_policy": "fresh, cited, no stale budget"
}
→ ContextPack {
send: ["latest approval", "open commitments", "recent spend"],
skip: ["old transcript noise", "superseded budget memo"],
result: "fewer prompt tokens, fresher evidence, replayable answer",
replay: "pack_2026-08-10T14:02Z"
}The platform
One context boundary, not another prompt template.
Production agents do not need a bigger prompt; they need live context infrastructure. MatrixArk gives vertical AI teams a single API to call with raw material and get back a prompt-ready pack that is smaller, fresher, cited, and replayable.
Vertical AI apps send whatever they have: raw user questions, tool traces, documents, source references, final answers, and lightweight scope hints. MatrixArk does the rest. It extracts entities, event types, timestamps, validity windows, and permissions; routes each record to the right store; keeps recent sequences and aggregates fresh; and, at request time, compiles a bounded, replayable context pack that fits a token budget.
The engine underneath is TemporalStore, the open-source time-aware serving core. MatrixArk keeps the customer API simple while the engine handles validated time windows, returned-result limits, dirty-summary markers, and replayable audits. Enterprise storage backends attach only when scale or consistency demand it.
What one request touches
A single call flows through six stages. Ingest and extract turn raw events into serving state; compile writes bounded records; retrieve, rank, and pack assemble the prompt and learn from the outcome.
1 · Ingest
Take the raw material
Messages, tool traces, docs, approvals, source refs, and final answers arrive through one context API.
2 · Extract
Find the context
Entities, event type, timestamps, validity, permissions, and prompt relevance are pulled from each event.
3 · Compile
Write bounded records
Scope hashes, context nodes, timestamped events, secondary indexes, and dirty summaries land in the store.
4 · Retrieve
Read within limits
Intent becomes time windows, filters, and candidate nodes; bounded reads return fresh facts and stale blockers.
5 · Rank
Score for the prompt
Candidates are ranked by freshness, authority, permission, and relevance against the request-time budget.
6 · Pack & learn
Return, then remember
A token-budgeted, replayable pack is returned; accepted answers, corrections, and outcomes are written back.
Enterprise benefits
Less token waste, better answers, and infrastructure that keeps up.
MatrixArk is built for enterprises running many agents, long histories, and high-volume online traffic. It compresses temporal context before the model sees it, separates compute from storage when deployments grow, and replaces a fragile chain of memory services with one governed context system.
Better LLM output quality
Freshness windows, permission filters, citations, and stale-context blocking reduce wrong answers caused by outdated memory. The model gets the current fact, the source, and the reason it was selected.
Compute/storage separation
Enterprise backends such as MatrixObject let stateless serving nodes read and write one durable shared store. Compute can scale for traffic spikes without copying every shard to every node.
Extreme concurrent reads and writes
The TemporalStore serving core uses WAL-first durability, memory indexes, SSD cache fill, and append-structured storage for very large concurrent agent writes, reads, replays, and feature updates.
One system instead of a stack to babysit
Memory, retrieval, temporal features, summaries, safety counters, replay, and audit share one serving boundary. Teams maintain fewer queues, caches, vector indexes, repair jobs, and consistency patches.
Native temporal compression
Long histories are summarized and tiered over time while remaining replayable. Conversation memory, tool traces, rollups, frequency caps, and distinct sets all benefit from the same temporal compression model.
Architecture
From the app to disaggregated storage, one enterprise context path.
The vertical AI app talks only to the MatrixArk context boundary. Below it, the open-source TemporalStore core serves time-aware reads and writes, backed by tiered memory, high-concurrency WAL/index paths, and enterprise storage when compute and storage need to scale independently.
Application
Vertical AI appraw query, hints, tool events, final answer
↓ one context API ↓
Context boundary
MatrixArkextraction · storage routing · freshness · ranking · pack assembly · replay
↓ serving calls ↓
TemporalStore serving core · open source
Proxyrouting & client API
Metaservershard map & membership
Datanodestime-aware reads & writes
↓ replication & cache ↓
Runtime dependencies
↓ context tiering ↓
Context tiering
Memoryhot bands & buckets
SSDwal & local shard
Shared storedurable pages & objects
↓ enterprise backends ↓
Storage backends Enterprise only
The app never touches storage directly. TemporalStore serves the common case from tiered memory and SSD; MatrixObject, MatrixKV, and MatrixDB join when disaggregated scale, transactional truth, or very large concurrent read/write workloads require the enterprise tier. Learn more in TemporalStore.
Open source
TemporalStore is published — the open-source stack is live.
The serving core and its runtime dependencies are open source and available today under the matrixarkai organization, Apache-2.0 licensed. Anyone can read, run, and self-host all three right now — TemporalStore, MatrixCache, and MatrixRaft. MatrixArk is the managed platform on top, not a gate in front.
Serving engine · Apache-2.0
TemporalStore
Time-aware serving engine: temporal KV, latest KV, validity windows, replayable context packs. Also at temporalstore.ai.
Serving cache · Apache-2.0
MatrixCache
Multi-tier serving cache that keeps hot bands and buckets in memory in front of the serving core.
Consensus · Apache-2.0
MatrixRaft
Raft consensus and a durable segmented log for replicated, crash-safe context state.
Start with the open-source stack today: browse the repos at github.com/matrixarkai or read the TemporalStore story at temporalstore.ai.
Compare
Where MatrixArk sits in the context landscape.
Memory frameworks and context databases proved the need. MatrixArk turns those patterns into one production serving boundary: durable temporal state, request-time freshness, and replayable prompt inputs.
| System | Approach | Temporal & replay | One service | Retrieval |
|---|---|---|---|---|
| MatrixArk / TemporalStore | Context boundary over a time-aware serving engine | Native time windows, validity, and replayable context packs | One API; extraction, routing, ranking, and packing built in | Filter-first traversal, optional vector recall |
| OpenViking / VikingMem | Hierarchical event/entity memory with L0/L1/L2 layers | Temporal compression; file-walk at prompt time | Memory layer; serving and storage assembled separately | Hierarchy traversal plus embeddings |
| Mem0 | Developer add/search memory APIs | Scoped memories; limited replay | Library plus a vector store | Configurable vector retrieval |
| Zep / Graphiti | Temporal knowledge graph memory | Bi-temporal graph; strong history | Graph service plus app-side assembly | Hybrid semantic, keyword, and graph |
| MemOS / Memori | Memory operating layer for agents | Memory lifecycle; replay varies | Framework over external stores | Pluggable retrievers |
What that means in practice
The frameworks above are strong at what they do: Mem0 makes memory a two-call API, Zep and Graphiti model history as a temporal graph, MemOS and Memori give agents a memory lifecycle, and OpenViking makes hierarchy intuitive. MatrixArk keeps the easy API shape and adds the parts production teams end up building themselves: bounded time-aware reads, request-time freshness, stale-memory blocking, permission-aware ranking, and a context pack you can replay for evals and audits.
The trade-off is deliberate. MatrixArk is infrastructure, not a drop-in library, so it rewards teams shipping durable agents over quick prototypes. Because the serving core is open source, you can adopt TemporalStore first and add enterprise backends later without changing the context API.
Benchmark headline
On a shared harness against OpenViking, TemporalStore matches or beats it: 42% vs 34.7% overall answer quality, 38% vs 16% on LongMemEval, and a 44% tie on LOCOMO — with a fair reader and the same embeddings on both sides.
Read the full method and numbers in the TemporalStore memory benchmark and the OpenViking product-parity guide.
Enterprise & operations
Run one governed context system in cloud or on premise.
MatrixArk runs as a managed service on AWS, GCP, or Azure, in your private cloud, or on premise for strict data, latency, sovereignty, or compliance needs. The payoff is not just uptime: one governed context system replaces the maintenance burden of stitching together vector search, caches, feature stores, queues, summarizers, and custom replay pipelines.
Enterprise storage backends attach to the same context path when scale or consistency demands it:
- MatrixObject Enterprise — enterprise object store for compute/storage separation (disaggregation), and for storing large files such as resource and skill files — the raw resource/skill blobs TemporalStore keeps out of the hot serving path, with only the pointer inline. See MatrixObject.
- MatrixKV Enterprise — low-volume transactional metadata for ownership, leases, approvals, and trusted control state. See MatrixKV.
- MatrixDB Enterprise — high-throughput KV for hot sessions, profile state, and cache metadata at scale. See MatrixDB.
None of these is required to start. The open-source TemporalStore core covers the common case; enterprise backends are an operational upgrade for larger scale, stronger separation of compute and storage, and higher sustained read/write concurrency.
Contact
Bring MatrixArk to your context layer.
Talk to us about production LLM context management: extraction, time-aware serving, freshness, replay, and enterprise storage for your agents.
Prefer the open-source path? Start with TemporalStore at temporalstore.ai and reach out when you need the managed platform.