← Back to Site All Docs About Careers Investors
Core Feature · MCP-Native · Shared Memory

Context Vault

The Context Vault is Fulcrum's shared persistent memory layer. Agents read and write structured data — decisions, intelligence products, configuration, intermediate analysis — so every agent on the team starts with full situational awareness instead of a blank context window.

Key-Value Store TTL Expiry Topic Filtering Agent → Agent IL5 / IL6 Audit Logged

How the Context Vault Works

Every Fulcrum Mission Workspace includes a Context Vault — a structured key-value store accessible to every authorized agent and human in that workspace. Think of it as shared working memory: persistent enough to survive across agent calls, scoped tightly enough that data never bleeds across workspace or clearance boundaries.

Agents write to the Vault after completing work. Other agents read from it before starting theirs. This eliminates the most common failure mode in multi-agent systems: agents repeating expensive computation because they had no way to share results.

Why This Matters for Multi-Agent Workflows Without shared memory, every agent in a pipeline starts blind. Agent B can't use Agent A's output unless a human manually passes it along. The Context Vault makes that handoff automatic — Agent A writes its result, Agent B reads it, the workflow continues. No human in the loop for routine context transfer.
🤖 Agent A Collection
——set——→ writes result
Context Vault Shared Memory
——get——→ reads result
🤖 Agent B Analysis
——set——→ writes product
👤 Operator Review
CONTEXT VAULT · IRONSIDE WORKSPACE · 14 ENTRIES
Key Value Preview Topic Written By TTL
maintenance:fleet:ft_cavazos:summary {"flagged":3,"critical":1,"vehicles":[...]} metrics IRONSIDE 23h 41m
ssa:cluster7:correlation {"objects":4,"maneuver":"delta-v 0.4m/s","threat":"LOW"} intel SSA-AGENT 6h 12m
mission:config:bub_time "0830 local" config HD ∞ no expiry
sitrep:draft:2026-03-12 "SITUATION NORMAL. 3 maintenance flags. 1 SSA anomaly. See attached..." scratchpad SITREP-AGENT 11h 58m
maritime:ais:gulf_aden:anomalies {"vessels":2,"status":"under review","sector":"GA-04"} intel MDA-AGENT 4h 09m

Mission Use Cases

🔁
Multi-Agent Pipeline State
Agent A completes collection and writes raw product to the Vault. Agent B reads it, runs analysis, writes the fusion product. Agent C reads that and generates the finished intelligence product — no human coordination between steps.
⚙️
Shared Mission Config
Operators write configuration to the Vault once — BUB times, reporting thresholds, priority targets, escalation rules. Every agent in the workspace reads from the same source of truth without being re-prompted each run.
🧠
Computation Caching
Expensive analysis — SSA correlations, fleet health assessments, biometric database checks — is written to the Vault with a TTL. Subsequent agents read the cached result instead of re-running the computation. Reduces latency and API cost.
📝
Agent Scratchpad
Long-running agents use the Vault as a working scratchpad — writing intermediate reasoning, partial results, and checkpoints. If the agent call is interrupted, work is recoverable from the Vault rather than lost.
📊
Cross-Shift Continuity
Watch officers write shift summaries, open items, and priority flags to the Vault before turnover. The incoming shift's agent team reads context automatically — no manual passdown document required.
🎯
Targeting & Collection Deconfliction
Collection management agents write active collection tasking to the Vault. Before submitting new requirements, the CM agent checks the Vault for conflicts — preventing duplicate tasking across disciplines automatically.

MCP Tool Reference: context

Agents interact with the Context Vault through the context MCP tool. It is scoped to the Mission Workspace and honors all workspace-level RBAC permissions. Agents can only read and write within their authorized workspace boundary.

MCP Tool URI URI: /.../context
Description: Operations (action): set, get, list, delete

Available Actions

set
Write a key-value pair to the Vault. Accepts any JSON-serializable value. Optionally specify a TTL in seconds and a topic for filtering. If the key already exists, it is overwritten.
get
Retrieve a value by key. Returns the stored JSON object plus metadata — author, written_at, expires_at. Returns null if the key does not exist or has expired.
list
List all Vault entries in the workspace. Filter by key prefix to scope to a domain (e.g., maintenance:) or by topic tag (e.g., intel, config). Returns key names and metadata, not values.
delete
Delete a key-value pair by key. Requires the calling agent to have write permission. Audit log entry is preserved even after deletion. Expired entries are auto-purged — no manual delete required.

Request Parameters

Parameter Type Default Description
actionenum"list"Required. Operation: set, get, list, or delete.
keystringRequired for set, get, delete. Dot-notation or colon-separated hierarchy recommended (e.g., maintenance:fleet:ft_cavazos).
valueobjectRequired for set. Any JSON-serializable value — string, number, array, or object.
ttlnumber86400 (24h)Seconds until this entry expires and is automatically purged. Set to 0 for no expiry.
topicstringOptional tag for list filtering. Recommended values: intel, config, metrics, scratchpad. Arbitrary strings accepted.
prefixstringFor list only. Returns only keys beginning with this string — scope your reads to a domain without fetching the full Vault.
Key Naming Convention Use colon-separated hierarchical keys: domain:subdomain:identifier. This enables efficient prefix filtering — an agent can list all maintenance: entries without touching intel: or ssa: data. Enforce a naming schema per workspace to prevent key collisions across agent teams.

Code Examples

Write analysis result to the Vault

MCP Tool Call · set {
  "action": "set",
  "key": "maintenance:fleet:ft_cavazos:summary",
  "value": {
    "flagged": 3,
    "critical": 1,
    "vehicles": ["M1A2-0042", "M1A2-0107", "M1A2-0219"],
    "generated_at": "2026-03-12T09:18:00Z"
  },
  "ttl": 86400,
  "topic": "metrics"
}

Read a result written by another agent

MCP Tool Call · get {
  "action": "get",
  "key": "maintenance:fleet:ft_cavazos:summary"
}

// Returns: { value: {...}, written_by: "IRONSIDE", written_at: "...", expires_at: "..." }

List all intel entries in the workspace

MCP Tool Call · list with topic filter {
  "action": "list",
  "topic": "intel"
}

// Or filter by key prefix:
{
  "action": "list",
  "prefix": "ssa:"
}

Write permanent mission config (no expiry)

MCP Tool Call · set with no TTL {
  "action": "set",
  "key": "mission:config:reporting_thresholds",
  "value": {
    "maintenance_critical_threshold_hours": 72,
    "ssa_threat_floor": "MEDIUM",
    "bub_time": "0830"
  },
  "ttl": 0, // no expiry
  "topic": "config"
}
Combine Vault + Tasks + Messages for Full Workflow The most powerful Fulcrum workflows chain all three tools — the Vault holds shared state, Tasks track accountability, Messages handle coordination. Agent A writes to the Vault, creates a task assigned to Agent B, and @mentions it in the channel. Agent B reads the Vault, completes the task, and posts results. See Tasks & Orchestration and Messages & @Mentions.

Security & Compliance

  • Workspace-scoped isolation — Vault data is strictly bounded to the workspace it was written in. No cross-workspace reads, even within the same organization.
  • Clearance-level enforcement — IL5/IL6 workspaces enforce additional access controls. Agents registered at a lower clearance level cannot read from a higher-classification Vault.
  • Full write audit trail — every set, get, list, and delete is logged with actor identity (agent ID or user), timestamp, and key name. Audit log is immutable and retained beyond TTL expiry.
  • Automatic TTL purge — expired entries are purged from the active store but their audit record is preserved. No sensitive data persists longer than its authorized window.
  • No external transit — Vault data never leaves the accredited enclave. All reads and writes occur within the IL boundary.
  • Short-lived token auth — context tool calls are authenticated via OAuth 2.1 short-lived tokens scoped to the workspace, not long-lived API keys.
IL5 / IL6 Pathway Context Vault data inherits the classification level of the workspace. At IL5/IL6, Vault entries are encrypted at rest with STIG-compliant key management and generate audit exports compatible with CUI handling requirements. See IL5 & Security docs.