Context platform
Use the full stack when LLM memory becomes production state.
Choose this path when context is not just memory anymore. TemporalStore owns time and low-latency context reads; Enterprise MatrixDB adds hot state; Enterprise MatrixKV protects permissions, approvals, leases, and committed agent truth. One context API hides the routing.
The core idea
Context is more than vector search.
A vector database can find semantically similar chunks. It cannot, by itself, decide which fact is current, which promise is still open, what the agent already tried, what the user is allowed to see, or what context was valid at a previous point in time. Those are the questions that decide whether a production agent is safe.
The full MatrixArk stack turns context from an application-side integration problem into a production state platform. TemporalStore answers time and speed. MatrixDB gives hot state and Redis-compatible adoption. MatrixKV protects truth, ownership, approvals, leases, and committed actions. Together they give builders one context surface instead of a pile of fragile glue.
The output is not a raw search result. It is a context pack: latest facts, relevant timeline, retrieved sources, permissions, stale-memory warnings, and citations — assembled within a token budget for one model call.
Boundaries
What the AI harness owns, what MatrixArk owns.
Vertical AI teams keep the experience, local context, model choice, and prompt style. MatrixArk owns the infrastructure decisions that are easy to get wrong at scale.
| Layer | AI harness owns | MatrixArk owns |
|---|---|---|
| User query | Raw request, UI state, selected entity, optional first-pass intent. | Validation, schema mapping, safe query plan, token budget, fallback route. |
| Local context | Open files, visible page, selected ticket, current draft, active tool state. | Durable cross-session memory, time validity, stale blocking, replay, source freshness. |
| Retrieval | Domain preferences and UX-specific ranking signals. | VectorDB/object coordination, TemporalStore freshness, MatrixKV permissions, MatrixDB hot state. |
| Write-back | User acceptance, tool outcomes, corrections, final answer, new local state. | Memory updates, commitments, rejected suggestions, replay ids, cache-invalidation hints. |
The API surface
A handful of calls; the routing stays hidden.
The full stack should feel small to customers. A vertical harness calls a few APIs while MatrixArk hides extraction, schema compilation, storage routing, time filtering, token budgets, and replay.
- /context/ingest — write messages, tool outputs, approvals, docs, and final answers.
- /context/retrieve — turn a raw query plus hints into a token-budgeted context pack.
- /context/feedback — record accepted answers, rejected context, corrections, commitments.
- /context/audit — explain selected refs, blocked refs, freshness checks, and budget use.
- /context/replay — rebuild what the model saw at a historical request time.
MatrixArk plans each query first. It builds a ContextPlan from the raw query, tenant hints, and session state — deciding intent, scope, time window, budget, and routes — then reuses that same plan to ingest the answer and guide follow-ups.
get_context_pack({
vertical: "support",
task: "draft_customer_reply",
entity_id: "customer_acme",
as_of_time: "now",
token_budget: 6000
})
returns:
latest_facts, relevant_timeline,
open_commitments, retrieved_sources,
blocked_context, stale_memories,
permissions, cache_policy,
prompt_sections, replay_idArchitecture
Three engines behind one context boundary.
MatrixArk reads time, hot state, and truth before the prompt is assembled, deciding which retrieved chunks, raw objects, memories, permissions, and time-valid facts should enter the prompt now — and which are stale, unauthorized, or superseded.
Why three engines win
Each owns a different production concern.
| Engine | Owns | Question it answers |
|---|---|---|
| TemporalStore | Timelines, memory deltas, tool history, freshness, replay, counters, sequences, cache eligibility. | What happened over time, and what is still valid now? |
| MatrixDB Enterprise | Hot session summaries, active profiles, cached retrieval results, TTL state, cache metadata, invalidation hints. | What hot state should be fetched fast on the request path? |
| MatrixKV Enterprise | Canonical facts, permissions, document versions, approvals, leases, checkpoints, committed actions. | What is approved, owned, and committed — without stale or duplicate reads? |
The hard part is not storing one memory. It is deciding, at request time, which memories are fresh, which sources changed, which prompt sections can be reused, which facts are canonical, and which tenant policy applies. MatrixArk keeps those concerns in one model instead of scattering them across framework code, cache keys, vector metadata, and service databases.
The position
The context state layer for production LLM agents.
MatrixArk should not be positioned as another vector database. The stronger position is the context state layer for production LLM agents: the infrastructure that decides what the model should know, trust, ignore, cite, remember, and forget. TemporalStore is the standalone starting point; the full stack adds hot state and trusted correctness when copilots need permissions, current facts, replay, and vertical-specific context rules.
Not sure which engine a workload belongs to? The state engine routing guide keeps teams infrastructure-agnostic, and what the KV stores add covers MatrixDB and MatrixKV in depth.
Keep reading