Cognitive Memory Database for AI Agents

Name: YantrikDB
Author: Yantrikos

Engine v0.23.0 · lexical fusion, reranked recall & the explain surface

Memory that just works.

Persistent cognitive memory for AI agents.

Your agent forgets your project between sessions. YantrikDB remembers — as an embeddable Rust engine, a Python package, an MCP server, or a replicated cluster.

Get started → Read the concepts

98.7% LongMemEval-S retrieval recall@40 Apache-2.0 open source Rust engine · Python + MCP

Installpip install yantrikdbcargo add yantrikdbdocker pull ghcr.io/yantrikos/yantrikdb

Three ways to run it

Same engine in all three. Pick the one that matches where your memory should live.

Embedded Agent (MCP) Network cluster

In your process. No server, no network.

The engine runs inside your application. Zero configuration — `with_default` picks the embedder for you, and an in-memory store never touches the network.

pip install yantrikdb

YantrikDB.with_default(":memory:") zero-config entry point

Best for: A single agent or app that owns its own memory
Latency: In-process — no network hop
Scope: One process. No sharing between machines

Run the contradiction demo →

Memory for a coding agent you already use.

The MCP server exposes memory as tools. Your client decides when to call them — the server ships instructions describing when memory should be used.

pip install yantrikdb-mcp

codex mcp add yantrikdb -- yantrikdb-mcp or Claude Code, Cursor, Windsurf

Best for: Giving an existing assistant memory across sessions
Control: The host client decides when a tool fires
Scope: One developer machine, one store

MCP setup →

Shared memory, replicated across nodes.

The server wraps the engine with authentication, multi-tenancy and YRP native replication, so several clients share one memory.

yantrikdb serve --data-dir ./data start command

Before this works: Create a database and token before connecting a client. Server quick start →

Best for: Several agents or people sharing one memory
Adds: Auth, multi-tenancy, replication, failover
Cost: Infrastructure to run and operate

Server install →

Several agents, one memory

The network layer is what makes memory shared. Each client authenticates, the server scopes it to a database, and they read and write the same store.

Claude Code
Cursor
Your service

yantrikdb-server token auth · database per tenant
One store namespaces scope records, recall, sessions, tasks
Replicas YRP replication · leader election · failover

Sharing happens through the server. The embedded engine and the MCP server are single-process — they own their own store and do not share it between machines. Client names are examples of MCP-compatible hosts, not integrations unique to this mode.

Launch film · 1:13

Memory that survives the handoff

One decision, three agents, and a shared store. The film follows a real captured trace through recall, namespace isolation, history, conflict review, and the memory lifecycle.

Read the transcript

Monday: Atlas moved. Thursday: another agent drafts the opposite.

Not careless. It has no memory to check.

With YantrikDB, the second agent asks first, and gets the decision, the source, and why it surfaced.

It is scoped. Atlas facts live in Atlas's namespace, and nowhere else.

It knows who owns it, and what it touches.

Procurement changed the answer. The record was corrected, not overwritten, so the old belief is still inspectable.

The store recognizes conflicting claims and routes them for review. Your policy decides.

Stale context fades. Related fragments consolidate when you ask. Important memories rise for attention.

Three agents. Three transports. One shared store.

YantrikDB. Memory that just works.

Memory Lab

Store three memories, recall against them, then store a fourth that contradicts the first — Acme is based in Boston. then Acme is based in Denver. — and run db.think(). It returns conflicts_found: 1, and both records still come back on the next recall, each carrying the dispute.

This runs in your tab. Rust compiled to WebAssembly — SQLite, the vector index and the scoring pipeline all local. No server, no API calls, nothing stored anywhere, and the state disappears when you reload.

One honest limit: the bundled embedder does not compile to wasm, so this page hashes words into 64-dim vectors instead of embedding them. The ranking is real; the embedding quality is not representative of the shipped engine.

What the demo will not pretend to show

Two numbers a four-memory store cannot honestly move, so the demo names them rather than printing a zero:

Consolidation waits for min_active_memories: 10.
Pattern mining is off in the default config.

Every other number on screen comes back from the engine itself. Nothing declares a schema — the extractor reads a headquartered_in claim out of each sentence, and that relation holds one value at a time, which is why the fourth memory registers as a conflict rather than an update.

Memory Atlas · fictional sample store

See what a store holds after six months

Every memory the store still holds, the entities the engine linked it to, the claims it backs, and the revision history of anything corrected. One static page, one data.json, no engine or model needed to look.

The Memory Atlas with a corrected memory selected in the work namespace: lines to the memories that share its entities, and an inspector showing the memory text, its connections, and a neighbour in the personal namespace.

Selected: a memory about a manager whose team changed in July 2026. The inspector shows the correction with its prior text, the claims it backs flagged as source revised after this claim, and the memories it reaches through shared entities, including one in the personal namespace.

Open the sample atlas → Export your own store →

Why this memory surfaced

A recall returns more than a list. Each result carries the signals the engine used to rank it, so you can see why something came back rather than trusting that it should have.

A worked example. Four memories stored, one query run, output captured from the engine itself and committed as a fixture — not computed on this page, and not written by hand.

query who is blocked on the auth rewrite

#1 The payments migration is blocked on the auth rewrite. 0.520

why_retrieved semantically similar (0.83)recentimportant (decay=0.80)

similarity

0.832

decay

0.800

recency

1.000

importance

0.800

valence multiplier

1.090
#2 Alice leads the payments team. 0.191

why_retrieved recentimportant (decay=0.90)

similarity

0.337

decay

0.900

recency

1.000

importance

0.900

valence multiplier

1
#3 Standup moved to 09:30 on Tuesdays. 0.066

why_retrieved recent

similarity

0.127

decay

0.300

recency

1.000

importance

0.300

valence multiplier

1

These signals do not add up to the score, and they are not meant to. They are diagnostic magnitudes that combine under the engine's scorer — some multiplicatively, some not — so reading them as percentages of a total would be wrong. Notice that #2 carries higher importance and decay than #1 and still ranks below it: similarity dominated.

Vectors are the demo's deterministic hash embedder, not the shipped embedder, which does not compile to wasm. No lexical signal appears here because the browser recall takes an embedding only.

The Problem

Many first-pass agent-memory systems follow the same loop:

Store everything. Embed. Retrieve top-k. Inject into context. Hope it helps.

That loop alone does not model a memory lifecycle. Without additional machinery, old memories do not decay, related records are not consolidated, and conflicting structured claims are not surfaced for review.

YantrikDB is built around those four gaps.

Every memory is treated as equal

Relevance gates every other signal multiplicatively — a perfectly relevant old memory surfaces, an irrelevant high-importance one does not.

Removing the additive recency wall moved end-to-end MRR from 0.054 to 0.541 on a labelled production clone.

Retrieval detail →

Old memories never fade

Temporal decay and consolidation run as a cognition pass rather than a cron job, so the store settles instead of only growing.

The write path →

Contradictions are never detected

Store “Acme is based in Boston.” then “Acme is based in Denver.” and think() returns conflicts_found: 1 — no schema declared, no rule written.

Detection works over relations the extractor recognises — here headquartered_in, which holds one value at a time — not over arbitrary sentences.

Run it yourself →

Nothing is ever connected

Typed nodes and typed edges — beliefs, goals, preferences, joined by supports, contradicts, causes — so recall can follow structure, not just similarity.

Cognitive state graph →

Encryption at rest, Knowledge Packs, cluster mode and the rest of the capability detail: what the engine does →

What it actually does

Those four gaps are the argument. This is the surface that answers them — grouped by what you are trying to do, with the real method names, because a capability you cannot call is a slogan.

Recall & ranking 6 Category spans Engine / PythonMCPServer HTTPBrowser (wasm)

Retrieval that returns why it returned something, not just what.

recall recall / recall_text: Rank by relevance and return a final score with retrieval reasons. Richer engine/Python surfaces expose the signal breakdown; leaner transports return the score and reasons.
Point-in-time recall recall_as_of: Ask what the store believed at a past moment, not just what it holds now.
Refine a recall recall_refine: Narrow an existing result set instead of re-querying from scratch.
Recall with links recall_with_links: Pull a memory together with the records it is linked to.
Relevance feedback recall_feedback: Mark a result useful or wrong and let ranking learn from it.
Entity expansion recall(expand_entities=True): Optionally widen a query along known entity edges; off by default so graph expansion is used deliberately. Opt-in per call. Enabling it by default measured worse on the cited set, so it is a deliberate choice rather than a mode.

Isolation & lifecycle 7 Category spans Engine / PythonMCPServer HTTPBrowser (wasm)

Memory that is scoped, and that ages instead of only growing.

Namespace isolation namespace=: Records, recall, sessions, tasks, procedures and statistics can be scoped by namespace. The network layer adds token-scoped tenant databases; namespace is a second scope inside an authenticated database where supported. The browser build uses a fixed default namespace.
Temporal decay half_life / decay: A half-life lowers a memory's ranking weight over time, so stale material stops dominating recall. Affects ranking weight — it does not destructively rewrite the stored importance.
Correct a memory correct / history: Correct in place while appending an auditable revision-history entry; entity links stay attached to the same record.
Forget forget: Tombstone a record so it stops surfacing.
Archive and hydrate archive / hydrate: Move cold memories out of the hot path and bring them back on demand.
Temporal queries stale / upcoming / range (or recall since/until): Find what has gone stale, what is coming up, and retrieve records from a bounded time window.
Maintenance cycle run_maintenance_cycle / maintenance_debt: Run upkeep explicitly and see what work is outstanding.

Entities & graph 6 Category spans Engine / PythonMCPServer HTTPBrowser (wasm)

Structure between memories, not just similarity between vectors.

Relate relate / unlink: Typed, weighted edges between entities.
Auto-relate auto_relate: Preview or persist co-occurrence-derived entity edges.
Search entities search_entities(pattern, entity_type, limit): Find entities by pattern and type.
Entity profile entity_profile: Everything the store knows about one entity, assembled.
Read edges get_edges: Traverse what an entity is connected to.
Relationship depth relationship_depth: How far apart two entities sit in the graph.

Cognition 6 Category spans Engine / PythonMCPServer HTTPBrowser (wasm)

The pass that notices contradictions instead of storing both quietly.

think() think(config): A bounded, incremental pass: consolidation and conflict scanning over what changed. Pattern mining is opt-in and off by default.
Conflict detection scan_conflicts / get_conflicts: Two claims that cannot both hold are flagged rather than silently coexisting. Covers recognised structured single-valued relations — not general natural-language inference over arbitrary sentences.
Resolution resolve_conflict / reclassify_conflict: An operator confirms which claim stands, with a note attached to the decision. Operator-driven by design; the database does not guess.
Disputed results disputed_with: Both sides of an open conflict keep coming back marked, so an agent can hedge.
Knowledge gaps knowledge_gaps: Questions asked often and answered badly, surfaced as gaps.
Substitution categories substitution_categories: Distinguish a real conflict from a redundant restatement.

Agent primitives 6 Category spans Engine / PythonMCPServer HTTP

The things an agent needs beyond storing text.

Sessions session_start / session_end / session_digest: Start, end and digest a working session; read its history.
Triggers get_pending_triggers / deliver_trigger / acknowledge_trigger: Proactive follow-ups the store raises, delivered and acknowledged.
Tasks task_add / task_list / task_update: Track work items alongside the memory they belong to.
Procedural memory record_procedural / surface_procedural / reinforce_procedural: Learn, surface and reinforce reusable strategies.
Skills & outcomes skill (MCP) · /v1/skills/*: A schema-validated skill catalog with semantic search and an append-only record of how each skill actually performed. Skill writes over MCP are operator-gated and off by default; reads and search are not.
Conversation ring record_turn / recent_turns: Recent turns kept as a rolling window for context.

Deployment & security 6 Category spans Engine / PythonMCPServer HTTP

What changes when memory stops living in one process.

Encryption at rest is_encrypted: AES-256-GCM over the store. Explicitly enabled, not automatic — engine, Python and host configuration. Encrypted mode can limit text extraction and search behaviour.
Knowledge Packs seal_pack / sign_pack / mount_pack / install_pack: Portable memory that can be sealed, signed, published and mounted into another store. Publisher trust, signature verification and embedder compatibility are part of the claim. Pack writes and trust changes over MCP are operator-gated.
Tenancy database / token: Token-scoped databases on the network layer, separate from in-database namespaces.
Replication cluster / health / metrics: Multi-node deployment with leader election and failover via YRP native replication.
Persistence provenance audit audit_leak_candidates: Find recent memory rows that lack both an originating oplog record and replication provenance.
Provenance gating provenance gate: Control what the store will accept based on where it came from.

Every capability, in detail →

Three experiments worth reading

Each one is the same shape: a real corpus, a question that a plain vector store answers badly, and a result you can inspect. Chosen because they test what the engine claims to do — hold conflicting accounts without silently picking one — not because they cover the widest range of subjects.

Which memory is stale? Several agents write to one store and disagree about the current state. think() flags the conflicting claims instead of letting the newest write win. Multi-agent ops → Testimony vs logs A witness account and a system log describe the same event differently. Both are retained and returned marked disputed, so neither is quietly dropped. Legal discovery → Four accounts, one event Every narrator is confident and none of them agree. The disagreement is the output rather than an error to resolve away. The Rashomon engine →

All eight experiments, with methodology →

Memory Failure Clinic

Your agent's memory failed. Bring the smallest version.

Replace private history with a tiny fictional timeline. We trace the write, extraction, indexing, recall, ranking, lifecycle, and integration path, then publish a reproducible diagnosis.

Open a clinic case How diagnosis works

01Reproducesynthetic timeline + exact versions
02Localizethe first failing lifecycle stage
03Resolvefix, regression test, or documented boundary

The ecosystem

One engine, and everything built around it. Grouped by what each piece actually is — a release artifact is not a product, and an experiment is not a supported component.