How it works
A deeper look at the architecture, data flow, and design decisions behind MemoryCrux.
The data pipeline
MemoryCrux processes knowledge through three stages. Each stage adds structure, verification, and searchability to raw information.
Ingest
Knowledge enters the system from multiple sources. You provide read-only API keys for platforms like OpenAI and Claude, and MemoryCrux syncs conversation history automatically. You can also upload conversation exports manually or push data via the API.
During ingestion, each piece of content is deduplicated against existing records using content hashing. New records are assigned a tenant, tagged with their source platform and ingestion timestamp, and queued for processing. API keys are encrypted via Vault Transit before storage.
Process and index
Each ingested record passes through the processing pipeline. Topics are extracted via entity recognition and clustering. The content is embedded using multiple vector models (Nomic 768-dim for primary retrieval, BGE-M3 1024-dim for cross-lingual coverage). A full-text keyword index is built in parallel for keyword-based search on Free tier.
The record is then hashed with BLAKE3 and signed via Vault Transit using Ed25519. This produces a provenance receipt that is appended to CoreCrux's event log. The receipt links the record to its exact content hash, source platform, and ingestion timestamp. From this point forward, the record's history is immutable and independently verifiable.
Serve via MCP
Agents connect to MemoryCrux through a standard MCP endpoint. When an agent calls a tool like query_memory, the request flows through VaultCrux's hybrid retrieval engine: vector search, keyword matching, reciprocal rank fusion to merge results, and optional cross-encoder reranking for precision.
Results are returned with confidence scores, freshness indicators, and provenance receipt IDs. The tool call itself is receipted, creating an auditable record of what the agent queried and what it received. Credit metering happens at this layer, with costs varying by tool complexity.
Decision tracking and causal chains
Every decision an agent makes is recorded as a first-class event in CoreCrux. The decision record captures the knowledge state cursor at decision time, the tool that was called, the confidence snapshot, and the outcome.
Decisions link to each other through causal chains. If an agent modifies an artefact, and another agent later reads that artefact and makes a further decision, the two decisions are connected in a navigable graph. You can walk the chain forwards ("what happened because of this decision?") or backwards ("what decisions led to the current state of this artefact?").
When a decision is later found to be based on stale or incorrect context, it doesn't get deleted. It gets superseded, with a pointer to the correction and a reason code (stale_context, incorrect_output, policy_violation, operator_correction, or agent_self_correction). The full supersession history is always navigable.
Constraints and pre-action verification
Constraints are the core safety mechanism. A constraint is a natural language assertion about an organisational boundary: "db-prod-01 is production; never run destructive commands without operator approval." MemoryCrux parses this into a structured record with scope, assertion, severity, and evidence fields.
When an agent calls check_constraints with a proposed action, two matching passes run. First, structural matching: if the action names a resource that appears in a constraint's scope identifiers, it matches deterministically. Second, semantic matching: the action is embedded and compared against constraint vectors. Matches above the similarity threshold are returned with confidence scores.
The verify_before_acting tool combines constraints with three other verification sources into a single pre-flight gate. It checks policy compliance (Shield), evidence sufficiency (Engine), active drift alerts (Watch), and organisational boundaries (Constraints). The result is a composite decision: proceed, warn, require_approval, or block. The most restrictive check wins. A signed receipt records exactly which checks were run and what they returned.
Example: a dangerous action gets caught
proposed_action: "Drop and recreate the users table on db-prod-01",
tool_name: "sql_execute"
)
Constraint match: "db-prod-01 is production. Never run destructive
commands without operator approval." (severity: critical, confidence: 0.97)
Receipt: crx_receipt_8f2a...
Drift detection and freshness
Knowledge goes stale. What was true last week may not be true today. MemoryCrux actively monitors the freshness of stored knowledge through the Watch subsystem.
Watch tracks five signal types: confidence band crossings (when a record's confidence moves outside its expected range), anchor drift (when the semantic distance between related records shifts significantly), receipt lineage changes (when a record's provenance chain is extended), retrieval regression (when search quality degrades for a topic), and load-bearing evidence swaps (when evidence that supports active constraints is superseded).
These signals feed into a composite pressure score per domain. High pressure means the knowledge landscape is actively shifting. Agents can check pressure before acting and exercise extra caution when conditions are volatile. Alerts surface through get_active_alerts and the raw signal stream is available via get_signals_feed.
Agent self-awareness
The most recent addition to MemoryCrux is Group E: Agent Effectiveness tools. These address a fundamental problem that the earlier groups don't solve. Groups A through D give agents access to knowledge, decisions, constraints, and monitoring. But they rely on the agent knowing what to ask for. An agent that doesn't know a domain exists won't query it.
assess_coverage solves this by analysing the knowledge base relative to a task description. Before an agent starts work on "migrate the payments service to the new Kubernetes cluster," it can ask: what do we know about payments? About Kubernetes? About migration procedures? The response tells it which domains have strong coverage, which are thin, and which have zero records.
get_relevant_context goes further. It assembles a task-shaped briefing compressed to fit within a token budget, with items ranked by risk-if-missed. Blocking constraints come first. Active alerts come second. Then approval-required constraints, stale decisions, warnings, and fresh knowledge. The agent knows exactly how much context was omitted, so it can decide whether to proceed or request more budget.
For long-running sessions, checkpoint_decision_state creates receipted snapshots that enable resumption from the last checkpoint rather than replaying the entire conversation. And when an agent encounters uncertainty beyond its authority, escalate_with_context packages its full reasoning state for human review, preserving the options considered, evidence gathered, and recommended action.
MCP integration
MemoryCrux is accessed exclusively through the Model Context Protocol (MCP). This means it works with any MCP-compatible client: Claude Desktop, VS Code with Copilot, Cursor, Windsurf, or any custom agent built on the MCP SDK.
Setup is a single configuration line pointing to the MemoryCrux MCP endpoint with your API token. From that point, all 29 tools are available to the agent as native tool calls. No SDK to install, no library to integrate, no API to learn. The agent discovers available capabilities through get_platform_capabilities and uses them through standard MCP tool invocation.
Configuration
{
"mcpServers": {
"memorycrux": {
"url": "https://mcp.vaultcrux.com/memory",
"headers": {
"Authorization": "Bearer YOUR_API_TOKEN"
}
}
}
}
Credit metering is transparent. Each tool call costs between 0 and 15 credits depending on complexity. The Free tier includes 100 credits per month. Every tool response includes the credit cost and a receipt ID. There are no hidden costs and no per-query pricing surprises.
Ready to get started?
Explore the full tool reference or sign up for early access.