Yantrikdb Hermes Plugin

This plugin makes YantrikDB the memory provider for a Hermes agent. Since v0.2.0 the default backend runs in-process — no separate server, token, or GPU — with a bundled potion-base-2M static embedder that loads on first call and stays in memory; an HTTP mode against a separate yantrikdb-server covers several agents or instances sharing one store. It is distributed as a standalone plugin because new memory providers are not merged into Hermes upstream.

The difference from a plain vector store is in what happens after a write. A think() maintenance pass canonicalizes duplicates, conflicts() and resolveconflict() surface and close contradictions instead of letting a superseded claim overwrite its replacement, recency-aware ranking keeps stale facts from outranking fresh ones without deleting them, relate() adds graph edges that boost related memories, and every recall result carries a whyretrieved list of the reasons it ranked where it did.

Twelve tools are exposed by default, covering remember, recall, forget, think, conflicts, resolve, relate, stats, and the trigger lifecycle that lets an agent list, acknowledge, dismiss, or act on the signals think() raises. Because tool schemas are re-sent every request, a core profile of 7 tools (about 1,725 tokens per turn) is the default and a full profile exposes all 18 (about 3,606 tokens); nothing is disabled by core, since consolidation runs at session end and conflicts, hygiene, and gaps surface in the system prompt. Three optional skill tools add agent-authored procedural memory with an outcome ledger.

Five lifecycle hooks bind it to the host: onsessionend consolidates, onprecompress injects high-salience memories before context compression so constraints survive long sessions, onmemorywrite mirrors built-in memory-file additions, onturnstart scales the prompt budget to the context the host reports as remaining, and on_delegation stores what a sub-agent returned as an episodic memory in the parent namespace. For always-on deployments that rarely hit a session boundary, consolidation and the gap-to-task loop also run on a turn-and-time cadence.

Operational features cover multi-user and multi-agent setups: owner scoping gives each person in a shared chat their own namespace, a shared-brain namespace lets explicit writes cross agents, a read-only fleet view reports sibling memory counts and open tasks, and signed knowledge packs can be mounted for a task and unmounted without changing your own memory. Standing rules written to a constitution file are injected first, are never trimmed under context pressure, still apply when the backend is unavailable, and have no editing tool.

Published measurements include a bundled recall benchmark (recall 0.865 at k=1 and 1.000 at k=3 and k=5, MRR 0.928 on a 40-memory, 37-query corpus) and steady-state embedded latencies of 0.60 ms median for a write and 2.58 ms for a recall, against 13.8 ms and 24.0 ms over HTTP. A 1000-fact, 20-query probe on a Hermes install recorded precision@5 of 0.80 over the 256 facts that landed before the engine's bounded ingest queue stopped accepting writes.

Features

• Embedded by default: an in-process engine with a bundled static embedder, plus optional larger model2vec or sentence-transformers embedders
• Contradiction tracking: conflicts() surfaces competing claims and resolve_conflict() closes them
• Explainable recall: every result carries a why_retrieved list of scoring reasons
• Graph edges: relate() links entities so related memories are boosted beyond semantic similarity
• Self-directing loop: recurring poorly-answered queries become knowledge gaps, then bounded tasks and a session agenda
• Knowledge packs: signed, sealed knowledge files mounted for a task and unmounted without altering your own memory
• Standing rules: a constitution file injected ahead of recalled memory, never trimmed and not editable by the agent