Vertical Cursors need a business context runtime.

In simple words

In one sentence: this page explains how we keep LLM context reliable in production. We store time, meaning, and trust signals so each request can use only the context that is still valid now.

Who should use this

Two Cursor options

Both options use the same API mindset: Cursor flow stays in place, MatrixArk handles context planning, time-window logic, filtering boundaries, and prompt assembly.

Easy integration pattern for enterprise Cursor users

For teams that are already on Cursor, the required integration is just two hooks and one token budget field. MatrixArk can work with only raw query + hints.

// Pre-LLM request sent to MatrixArk (enterprise Cursor usage)
get_context_pack({
  workspace: "company_a/platform_infra/project_1",
  raw_user_query: "Can we buy another GPU batch?",
  cursor_context: {
    user_id: "u_9001",
    session_id: "s_2001",
    app_path: "project_budget"
  },
  max_context_tokens: 3000
})

// Post-LLM event written back to MatrixArk
ingest_context_event({
  workspace: "company_a/platform_infra/project_1",
  event_type: "assistant_answer_final",
  happened_at: "2026-06-12T10:00:04Z",
  data: {
    context_pack_id: "ctx_123",
    answer_summary: "Another GPU batch is allowed if spend stays under $50,000.",
    accepted_by_user: true,
    memory_updates: ["Validate approval date before next purchase"]
  }
})

In this direct model, most teams start with TemporalStore for request-time context, use MatrixDB for hot latest-state reads when needed, and add MatrixKV for committed approvals, ownership, and workflow truth.

Ingestion without workflow friction

MatrixArk can operate with minimal input. If we only receive raw query + local hints before LLM call, it still produces a usable context pack by applying default policies and context templates.

This split keeps Cursor integration low-friction and lets enterprises improve quality incrementally. Every extra stream can be added as a hook without changing Cursor UI or workflow code.

What we learn from Zep and Mem0

The market is converging on a simple lesson: customers do not want to hand-build memory databases. Zep shows that apps can send messages, text, and JSON business data into a managed context layer. Mem0 shows that developers like a small add/search API where the service extracts durable memories and returns them later as prompt context.

The key difference is that MatrixArk is not only a memory extraction API. It is a serving contract: online ingestion, bounded TemporalStore queries, context-pack assembly, replay, and enterprise policy in one request path.

Replacing filesystem context with TemporalStore + Milvus

Filesystem-style context works because paths are intuitive. The limitation is that a filesystem is not a serving model for time-aware LLM context. MatrixArk keeps the path experience, then compiles it into three production layers.

logical path:
  /company_a/platform/project_1/approvals/alice-budget.md

TemporalStore ContextNode:
  node_id = node_approval_001
  scope_layers = [company_a, platform, project_1, approvals]
  scope_hash_chain = [h(company_a), h(company_a/platform), h(company_a/platform/project_1)]
  serving_scope_hash = h(company_a|platform|project_1)
  level = L2
  valid_from = 2026-06-10T09:30:00Z
  lifecycle_state = active
  embedding_refs = [emb_l0_001, emb_l1_001, emb_chunk_001]
  object_ref = s3://company-a/raw/approvals/alice-budget.md

Milvus EmbeddingRecord:
  embedding_id = emb_l0_001
  node_id = node_approval_001
  text = "Alice approved a $50,000 GPU budget for Project 1."
  vector = [...]
  scalar fields = tenant, project, collection, level, updated_at

Query flow: semantic candidates, temporal validation

Milvus should find candidates by meaning. TemporalStore should decide whether those candidates are fresh, valid, permissioned, scoped, and worth spending tokens on.

This is the key difference from filesystem retrieval: the final prompt is not whatever path was semantically close. It is the subset of candidates that pass TemporalStore's time, scope, lifecycle, permission, replay, and token-budget rules.

Two APIs, not one overloaded memory call

Query-time requests and non-query ingestion events should stay separate. This keeps the customer contract simple and lets MatrixArk optimize each path independently.

// Query-time read: raw query + hints.
get_context_pack({
  tenant_id: "company_a",
  raw_query: "What did we decide about Project Alpha vendor?",
  hints: {
    project: "Project Alpha",
    time_range: "last_30_days",
    max_context_tokens: 2500
  }
})

// Non-query write: teach MatrixArk what happened.
ingest_context_event({
  tenant_id: "company_a",
  event_type: "assistant_final_answer",
  event_time: "2026-06-13T20:00:00Z",
  content: "Project Alpha will use Vendor B after Vendor A failed security review.",
  hints: {
    project: "Project Alpha",
    remember: true,
    category: "decision"
  }
})

Enriched integration diagrams

In Option 1, the vendor-side flow is stable and low-latency: one context request before model call, one model call, one writeback after answer.

In Option 2, teams avoid changing user-facing behavior and still get time-aware context, reuse signals, and governance for critical actions.

Local context is not enough

A coding assistant can often answer from local workspace context. A vertical AI product needs more than local files. It needs to know what happened across sessions, which facts are still valid, what the team already approved, what the customer was promised, what source version is canonical, and which prior action should not be repeated.

What this is for

MatrixArk turns vertical AI products into an operational memory layer for daily workflows. Cursor-like teams should focus on outcomes, not data model design.

Cursor workflow, MatrixArk execution

Cursor should treat MatrixArk like an execution service: send raw user signal and local hints, get back a prompt-ready context pack. MatrixArk handles interpretation, filter selection, time-window rules, permissions, and routing.

How ingestion works

The vertical Cursor, workflow engine, webhook, or backend writes domain events directly to MatrixArk. Each record carries a workspace path, timestamp, and normal domain JSON. Think of these writes as registered hooks on your event stream. MatrixArk decides which fields become temporal context, source references, permissions, and replay metadata.

ingest_context_record({
  workspace: "company_a/platform_infra/project_1",
  event_type: "cost_update",
  happened_at: "2026-06-11T14:15:00Z",
  data: {
    actor: "finance_owner",
    amount: 18420,
    status: "committed",
    project_id: "project_1",
    reason: "llm_evaluation"
  }
})

The customer sends normal domain JSON. MatrixArk maps it to the model, extracts the timestamp and important fields, builds event sequences and summary signals, stores large objects by reference when needed, and records enough metadata for replay.

Ingestion before and after the model answer

A vertical Cursor sends a minimal context signal before asking for a context pack. Extra ingestion can be added during the response flow and after the answer for better continuity. This is how TemporalStore becomes living memory instead of a one-time retrieval system.

// Before retrieval: capture current working state.
ingest_context_event({
  workspace: "company_a/platform_infra/project_1",
  event_type: "user_query",
  happened_at: "2026-06-12T10:00:00Z",
  data: {
    raw_user_query: "Can we buy another GPU batch?",
    active_page: "project_budget",
    selected_entity: "project_1"
  }
})

// After model output: teach the next request what happened.
ingest_context_event({
  workspace: "company_a/platform_infra/project_1",
  event_type: "assistant_answer_final",
  context_pack_id: "ctx_123",
  happened_at: "2026-06-12T10:00:04Z",
  data: {
    answer_summary: "Another GPU batch is allowed if spend stays under $50,000.",
    accepted_by_user: true,
    new_commitments: ["Use spot instances where possible"],
    memory_updates: ["GPU spend decision should check Alice's June 10 approval"]
  }
})

Simple outside, optimized inside

Customers stay in the business experience. MatrixArk receives workspace context signals and turns them into strict internal shape. No manual tree-walk, no custom query planning for Cursor teams.

what the customer sees:
  tenant=company_a, project=project_1, workflow=budget_purchase

what MatrixArk creates inside TemporalStore:
  context boundary = tenant/project scope
  temporal event sequence = latest operational trail
  service index set = MatrixArk-managed, budgeted serving keys
  fallback summary pack = broad query outputs written back when needed

MatrixArk owns the hard parts: scope shaping, index selection, timestamp ordering, scan limits, freshness rules, and prompt rendering.

Serving-time query

When the user asks a domain question, the vertical Cursor should not construct TemporalStore filters itself. It should send the raw user request plus lightweight context hints. MatrixArk owns the context-planning step, including an optional small LLM call that turns the raw request into a safe structured plan. If the vertical Cursor already ran its own first LLM pass, it can send that interpreted plan to MatrixArk so MatrixArk can skip the extra planning LLM call and move directly to validation.

// Mode A: MatrixArk plans from raw query.
get_context_pack({
  workspace: "company_a/platform_infra/project_1",
  raw_user_query: "Can we buy another GPU batch?",
  hints: {
    active_page: "project_budget",
    selected_entity: "project_1",
    local_summary: "User is reviewing GPU spend."
  },
  max_context_tokens: 3000
})

// Mode B: Cursor already used its own LLM to understand the query.
get_context_pack({
  workspace: "company_a/platform_infra/project_1",
  raw_user_query: "Can we buy another GPU batch?",
  harness_plan: {
    task_type: "purchase_decision",
    needed_context: ["latest_budget_approval", "committed_gpu_spend", "open_commitments"],
    domain_terms: { "GPU batch": { context_bucket: "costs", category: "gpu_compute" } }
  },
  max_context_tokens: 3000
})

The customer asks a business question. MatrixArk either extracts intent itself or accepts the harness-provided intent plan. In both modes, MatrixArk maps phrases like "GPU batch" and "can we buy" to the platform's context model, validates the plan, chooses stores, and sends structured bounded inputs to TemporalStore. The final model receives the context that matters now, not a raw dump of every record.

MatrixArk plans; TemporalStore serves

MatrixArk should own the safe serving plan. It can use a small planning LLM to understand the raw user query, or it can accept a harness-provided plan when the vertical Cursor already did that first LLM pass. Either way, a deterministic planner validates the plan against tenant policy, permissions, indexes, and serving thresholds. TemporalStore should receive only structured, bounded queries.

MatrixArk context-planning LLM output:
  task_type = purchase_decision
  needed_context = [latest_budget_approval, committed_gpu_spend, open_commitments]

MatrixArk deterministic serving plan:
  approvals.latest_active(type = cloud_budget, as_of = request_time)
  costs.sum(category = gpu_compute, since = approval.valid_from)
  commitments.open(scope = project_1)
  stale_context.blocked(scope = project_1)

If the request is too broad:
requires_offline_aggregation({
  reason: "query exceeds online filter and scan guardrails",
  rejected: ["cross_project_scan", "fuzzy_filter", "group_by"],
  suggestion: "narrow scope, use declared index, or read SummaryFact"
})

Cursor-like products may send hints because they know the UI and local state. They should not need to send TemporalStore index names, HASH keys, SQL, or storage routing choices. MatrixArk owns those details so every vertical Cursor can stay infrastructure-agnostic.

When TemporalStore is not the right engine

TemporalStore should protect the prompt-time serving path. Some customer questions are too broad or exploratory for that path: arbitrary JSON filters, fuzzy search, all-team scans, long-range reports, joins, and group-by analytics. MatrixArk should still support those use cases, but route them to the right layer instead of forcing TemporalStore to behave like an OLAP database.

same customer event:
  approval/cost record arrives once

MatrixArk storage plan:
  TemporalStore:
    latest active approval, recent costs, open commitments
  MatrixDB:
    project current-spend summary, active session, cache metadata
  OLAP / HSAP:
    full JSON event, long-range analysis, dashboards, ad hoc filters

future prompt:
  OLAP result -> SummaryFact -> TemporalStore context pack

This keeps the customer experience simple. The vertical Cursor sends the raw request and optional hints. MatrixArk decides whether the answer should come from TemporalStore, MatrixDB, an OLAP/HSAP layer, or a precomputed summary written back into TemporalStore.

Why this is a flagship use case

Vertical Cursors are a natural buyer because their core challenge is not generic chat memory. Their challenge is domain context: custom objects, time validity, team decisions, approvals, source versions, permissions, and replayable prompt inputs.

The product message

MatrixArk gives vertical Cursor companies the missing backend for domain context: time-aware memory, domain-aware runtime models, online serving queries, stale-context blocking, runtime reuse signals, and replayable context packs.

The harness keeps the interface, workflow, model, and prompt style. TemporalStore provides the context filesystem behind it: what happened, what is valid now, what was approved, what is stale, and what should enter the prompt.