yantrikdb-hermes-plugin

YantrikDB as a memory provider for Hermes Agent. Self-maintaining memory — canonicalizes duplicates, surfaces contradictions, explains recall — in a drop-in plugin. As of v0.2.0 the default backend is in-process (pip install and go, no separate server).

This repository is the canonical distribution. Per Hermes maintainer guidance, new memory providers aren't being merged upstream — the recommended pattern is standalone plugins that users install via pip and register with their Hermes home directory. That keeps the version cadence, CI gating, issue triage, and review cycle on the plugin author's side, so fixes ship the same day they're ready instead of waiting on upstream review bandwidth.

Why this exists

Two recurring observations from the Hermes community map directly to what yantrikdb does:

"Compression was silently dropping earlier constraints by turn 50." — Hermes developer building a long-running coding agent (user-stories)

The on_pre_compress hook injects the highest-salience memories before Hermes compresses, so constraints survive long sessions. Recency-aware ranking + conflicts() makes superseded claims visible instead of letting them silently outrank their replacements.

"Spent 200-400 hours building a memory kernel because standard vector approaches dropped important constraints; successful implementations used temporal context graphs with lifecycle management — promotion / demotion / supersession — rather than vector similarity alone." — Hermes developer who built their own memory layer after vector approaches failed (user-stories)

This is the substrate yantrikdb already ships: temporal context graph via relate(), lifecycle via consolidation_status + forget() + the think() maintenance pass, recency ranking, first-class conflicts/canonicalization. Drop-in via hermes plugins install. The 200-400 hours are someone else's; you get the substrate.

And what other Hermes memory providers don't have

End-to-end demo — substrate growing through the skill lifecycle

Six skills from prior sessions, color-coded by type. Session 1: the agent adds a 7th (pink, just-created). Session 2 search highlights the relevant node, outcome recorded turns it green. Source: demo_visual.py.

What's actually running underneath

gpt-4o-mini receives the plugin's 15 tool schemas via OpenAI's chat-completions API and chooses when to call each one. In session 1 it autonomously picks the skill_id (release.yantrikos.clean), applies_to tags, and body for a workflow it just learned. In session 2 — fresh provider instance, same substrate — it searches the substrate, finds the skill, follows it, and records an outcome. Two real rids land. The autonomy loop closes in ~10 seconds.

Sources: demo_llm.py + transcript-llm.txt + demo_llm.tape for rendering. A scripted (no API key required) deterministic version is also included: demo.py / demo.gif.

The plugin's handle_tool_call dispatch path you see in both demos is the same entry point Hermes invokes internally. For larger-scale evidence of LLM-driven autonomy: yantrikdb.com/guides/autonomous-skills/ documents 17 skills authored by Claude across many sessions on one production substrate, with 9 showing cross-session reuse via the outcome ledger.

Install (default — embedded backend)

The v0.2.0 default backend is in-process: no separate server, no token, no GPU, no network. Bundled potion-base-2M static embedder (~8 MB, dim=64) loads on first call (~80 ms one-time warmup) and stays in-process.

Option A — hermes plugins install (v0.4.5+, one command for the plugin source)

source ~/.hermes/hermes-agent/venv/bin/activate
hermes plugins install yantrikos/yantrikdb-hermes-plugin
pip install yantrikdb                    # ~10 MB; in the same Python env as Hermes
hermes memory setup                      # → Select "yantrikdb" and press Enter
hermes memory status                     # → Provider: yantrikdb  Status: available ✓

hermes plugins install clones the repo into ~/.hermes/plugins/yantrikdb/ based on plugin.yaml's name: field. The pip install yantrikdb step gets the engine — hermes plugins install doesn't auto-install pip dependencies, so this is a separate step. Crucially: pip-install into the same Python environment Hermes runs from. If Hermes was installed via pipx, use pipx inject hermes-agent yantrikdb. If you're using a regular venv, source it first.

If your Hermes environment uses uv and does not have pip available, install with the Hermes Python explicitly:

uv pip install --python ~/.hermes/hermes-agent/venv/bin/python yantrikdb

Option B — pip install yantrikdb-hermes-plugin (bundled package path)

source ~/.hermes/hermes-agent/venv/bin/activate
pip install yantrikdb-hermes-plugin     # pulls yantrikdb engine + the provider source
yantrikdb-hermes install                # registers ~/.hermes/plugins/yantrikdb
hermes memory setup                     # → Select "yantrikdb" and press Enter
hermes memory status                    # → Provider: yantrikdb  Status: available ✓

If your Hermes environment uses uv and does not have pip available, install with the Hermes Python explicitly:

uv pip install --python ~/.hermes/hermes-agent/venv/bin/python yantrikdb-hermes-plugin
~/.hermes/hermes-agent/venv/bin/yantrikdb-hermes install

yantrikdb-hermes install registers the pip-installed provider with Hermes by creating a lightweight shim at ~/.hermes/plugins/yantrikdb (or $HERMES_HOME/plugins/yantrikdb). The shim imports the real provider from the installed yantrikdb-hermes-plugin package, so future package upgrades are picked up without copying the whole provider tree. Use yantrikdb-hermes install --copy if your environment prefers a physical copy instead of the default shim.

Updating

Option A updates the plugin checkout and the engine dependency separately:

source ~/.hermes/hermes-agent/venv/bin/activate
hermes plugins update yantrikdb
pip install --upgrade yantrikdb
hermes gateway restart                    # if Hermes is running as a gateway/service
hermes memory status

If your Hermes CLI does not have hermes plugins update, reinstall the plugin source in place:

hermes plugins install yantrikos/yantrikdb-hermes-plugin --force

Option B updates the pip package, then refreshes the registered shim:

source ~/.hermes/hermes-agent/venv/bin/activate
pip install --upgrade yantrikdb-hermes-plugin
yantrikdb-hermes install --force
hermes gateway restart                    # if Hermes is running as a gateway/service
hermes memory status

For uv-only environments, target the Hermes Python explicitly:

uv pip install --python ~/.hermes/hermes-agent/venv/bin/python --upgrade yantrikdb
uv pip install --python ~/.hermes/hermes-agent/venv/bin/python --upgrade yantrikdb-hermes-plugin

--force replaces the registered plugin directory. Back up any plugin-local files first if you keep custom files under ~/.hermes/plugins/yantrikdb/; normal YantrikDB settings belong in ~/.hermes/.env and are not touched.

Uninstalling

Option A uses Hermes' plugin manager for the plugin source, plus pip for the engine dependency:

source ~/.hermes/hermes-agent/venv/bin/activate
hermes plugins remove yantrikdb
pip uninstall yantrikdb
hermes memory setup                      # choose another provider, or disable external memory
hermes gateway restart                   # if Hermes is running as a gateway/service

Option B removes the user-plugin registration, then optionally removes the pip packages:

source ~/.hermes/hermes-agent/venv/bin/activate
yantrikdb-hermes uninstall
pip uninstall yantrikdb-hermes-plugin yantrikdb
hermes memory setup                      # choose another provider, or disable external memory
hermes gateway restart                   # if Hermes is running as a gateway/service

If your installed version does not yet have yantrikdb-hermes uninstall, remove the registration manually:

rm -rf ~/.hermes/plugins/yantrikdb
pip uninstall yantrikdb-hermes-plugin yantrikdb

Same-venv guidance (both options)

yantrikdb and yantrikdb-hermes-plugin must be importable from whatever Python interpreter Hermes uses:

• pipx install hermes-agent → pipx inject hermes-agent yantrikdb yantrikdb-hermes-plugin
• Default Hermes venv → source ~/.hermes/hermes-agent/venv/bin/activate first, then pip install ...
• Other plain venv → source path/to/hermes-venv/bin/activate first, then pip install ...
• uv-only venv → uv pip install --python path/to/hermes-venv/bin/python ...
• System Python → just pip install

If hermes memory status shows Status: not available ✗ after install, the most common cause is the plugin landed in a different Python than Hermes is using. which hermes && which python will confirm.

Optional: tier up the embedder

echo "YANTRIKDB_EMBEDDER=potion-base-8M" >> ~/.hermes/.env     # 28 MB, dim=256, ~92% MiniLM
# or potion-base-32M for 121 MB, dim=512, ~95% MiniLM
# or multilingual via the v0.4.2 model2vec path:
echo "YANTRIKDB_EMBEDDER_MODEL2VEC=minishlab/potion-multilingual-128M" >> ~/.hermes/.env
# or the broader HF ecosystem via sentence-transformers:
echo "YANTRIKDB_EMBEDDER_HF=sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2" >> ~/.hermes/.env

Optional: quiet the HuggingFace embedder

YANTRIKDB_EMBEDDER_HF uses sentence-transformers, which by default emits noise to stdout — tqdm progress bars on every encode and a one-time HF Hub auth warning at startup. The plugin disables the per-encode progress bars internally (v0.4.12+). For the rest, add to your .env:

HF_HUB_DISABLE_PROGRESS_BARS=1
TRANSFORMERS_VERBOSITY=error
# Optional, when running fully offline after the first download:
HF_HUB_OFFLINE=1

Without these, sentence-transformers / huggingface_hub output can pollute the agent's own stdout stream.

Install (alternative — HTTP backend, for HA cluster setups)

If you run multiple Hermes instances that need to share one memory store, or you want HA via raft:

docker run -d -p 7438:7438 -v yantrikdb-data:/var/lib/yantrikdb \
  --name yantrikdb ghcr.io/yantrikos/yantrikdb:latest
docker exec yantrikdb yantrikdb token --data-dir /var/lib/yantrikdb \
  create --db default --label hermes
# → ydb_abc123...

cat >> ~/.hermes/.env <<EOF
YANTRIKDB_MODE=http
YANTRIKDB_URL=http://localhost:7438
YANTRIKDB_TOKEN=ydb_abc123...
EOF

Same plugin, same 8 tools, same hooks, same provider contract — just talks HTTP to a separately-managed server instead of running the engine in-process.

Full config, tool reference, troubleshooting: yantrikdb/README.md.

What it does

The differentiator versus other Hermes memory plugins is not the vector store — it's what happens after the write:

Twelve tools exposed to the agent by default: yantrikdb_remember, _recall, _forget, _think, _conflicts, _resolve_conflict, _relate, _stats, plus the trigger-lifecycle consumers _pending_triggers, _acknowledge_trigger, _dismiss_trigger, _act_on_trigger (v0.4.13+). Three additional opt-in skill tools (v0.3.0+): _skill_search, _skill_define, _skill_outcome — see Skills below.

Tool response envelope (v0.4.16+)

Every tool response carries the same four envelope fields so an LLM later asked "what did I just do?" can't confabulate success on a silent failure:

{
  "status": "ok" | "failed",
  "ok": true | false,
  "tool": "yantrikdb_remember",
  "ts": 1748394801.42,
  ...tool-specific keys preserved verbatim (rid, stored, results, ...)
}

Failure responses additionally carry error (legacy key) and reason (alias). The envelope is purely additive — existing agent code that reads rid / stored / results / etc. continues working unchanged.

Why this matters: tool failures used to be communicated as {"error": "..."} only. When the agent's narrative LLM was later asked to summarize the session, it could confabulate plausible completion because the failure wasn't loudly present in machine-readable form. The new status: "failed" + ok: false are intentionally redundant — the word "failed" lands during narrative summarization, the boolean lands for programmatic consumers. Pattern documented by yantrikdb-agi after a real incident where the agent described a telegram_send that never happened.

Trigger lifecycle (v0.4.13+)

yantrikdb_think flags redundancies, conflicts, and surprise cross-domain connections as triggers — substrate signals the agent can inspect and close out:

• yantrikdb_pending_triggers — list what's waiting (with urgency, reason, suggested_action, and the source_rids that produced it).
• yantrikdb_acknowledge_trigger — agent saw it, no follow-up needed.
• yantrikdb_dismiss_trigger — false positive or out of scope.
• yantrikdb_act_on_trigger — agent took action; records an audit-trail entry.

All three closers remove the trigger from pending_triggers. Without these tools (pre-v0.4.13) the pending queue grew indefinitely because the producer (think()) had no matching consumer surface.

Compared to other Hermes memory providers

Each row in the table below is backed by tests/comparison/findings_scale_lxc/<provider>/ — the actual findings_scale.yaml, transcript.md, and raw/ response capture from running a 1000-fact + 20-query probe against that provider on a real Hermes 0.9.0 install (LXC 129, commit 4610551). The corpus is deterministic (fixtures/corpus_1k.json, seed=20260512: 600 realistic agent-memory facts + 300 noise + 50 planted duplicates + 50 planted contradictions); the probe is provider-agnostic and reproducible. Methodology details in tests/comparison/README.md.

Where the verified data lives — every cell in the table maps to a file:

• findings_scale.yaml — structured cells (the table is generated from these by compare.py)
• transcript.md — human-readable session log with timing
• raw/recall-Q*.json — captured raw recall responses for every query
• fixtures/corpus_1k.json, fixtures/queries_1k.json — the deterministic corpus + queries used

How to re-run it — clone the repo, scp tests/comparison/ to a Hermes-installed machine, python3 runner_scale.py --all. The harness will skip-with-honest-reason for any provider whose is_available() returns False (e.g. missing API key); for the ones that initialise, it produces a fresh findings_scale.yaml. Pull requests welcomed when accounts unlock more rows.

Three optional lifecycle hooks: on_session_end auto-consolidates, on_pre_compress preserves high-salience memories through context compression, on_memory_write mirrors built-in MEMORY.md / USER.md additions.

Skills (opt-in, v0.3.0+)

Skills are procedural memory: reusable patterns the agent distills from observed success and pulls back next session. They live in YantrikDB's shared skill_substrate namespace alongside skills authored by other consumers (Lane B SDK, server handlers, WisePick). Hermes-authored skills are tagged metadata.source=hermes so any downstream consumer can filter them in or out cleanly.

Disabled by default. Adding the plugin to an existing Hermes install doesn't change the tool schema the model sees. Enable explicitly when you want the agentic skill loop:

echo "YANTRIKDB_SKILLS_ENABLED=true" >> ~/.hermes/.env

When enabled, three new tools join the schema:

The agentic loop closes: agent observes a successful sequence → distills it via define → next session pulls it via search → records outcome via outcome → over time, ranking reflects what actually works.

Lifecycle distinction worth understanding. Hermes' own filesystem skills ($HERMES_HOME/skills/*.md) are human-authored, durable, version-controlled. YantrikDB skills are agent-authored, runtime-evolving, semantic-search-queryable. Different kinds of canonical, not competing authorities. The model picks by lifecycle.

Explainability is a side effect, not a bolt-on

Every recall() result already carries the structured ranking-reason list — that's the engine's standard response shape. The model can read it without prompt engineering. From the live Hermes session captured in VERIFICATION.md, DeepSeek's natural-language summary of the recall:

"All 3 memories returned, ranked by relevance × recency × importance. The top result ranked highest (semantic match + keyword + high importance + recency), followed by [...] (keyword match), then [...] (high importance but no direct keyword overlap)."

DeepSeek wasn't told the reason codes existed; it parsed them from the tool response and reflected them in its explanation. That's the architectural shape we wanted: the explainability surface is the recall response itself, transport-agnostic, model-agnostic, and visible to anyone who looks at the JSON. No separate "explain" tool. No second LLM call. The cost of explainability is zero because it was never separate.

Verification

• 96 unit tests covering request formation, error taxonomy, provider contract, hook semantics, circuit breaker, text truncation, mode-aware availability — all mocked, no network required.
• 2 live integration tests (tests/integration/test_live.py) that exercise the full flow against a real yantrikdb-server. Skipped by default; run with YANTRIKDB_INTEGRATION_URL + YANTRIKDB_INTEGRATION_TOKEN set.
• End-to-end Hermes demos against an unmodified Hermes 0.9.0 install for both backends, captured in VERIFICATION.md — DeepSeek-driven sessions calling all 8 tools, with why_retrieved reason codes flowing through the model's reasoning verbatim.

Performance (steady-state, post-warmup)

Even embedded p99 tail latency is faster than HTTP p50 — bad-case embedded beats typical-case HTTP. Long-running soak validation is in progress upstream (yantrikos/yantrikdb saga task #2); these numbers are 100-iteration micro-benchmarks, not 24-hour production traces.

About the embedder quality claims

Tier 1 (with_default(), ~8 MB) uses potion-base-2M via model2vec-rs — a pure-Rust static embedding (lookup table + mean-pool + L2-normalize), no transformer forward pass. Tier 2 (potion-base-8M, 28 MB) and Tier 3 (potion-base-32M, 121 MB) trade larger model files for higher recall and live behind set_embedder_named() (downloaded on first use, cached under user data dir).

Quality numbers cited in this README are R@5 vs sentence-transformers/all-MiniLM-L6-v2 (dim=384) on the upstream evaluation corpus. The "~89% / ~92% / ~95% of MiniLM" approximations are from that specific eval; your mileage will vary on a different corpus or task. Semantic separation is also corpus-size dependent — at 3 records all vectors look similar (top score ~0.58); at 8+ with real diversity the score range opens up (top score ~0.84). If you're evaluating, run against your own data.

CI runs ruff + mypy + pytest on Python 3.11 / 3.12 / 3.13 / 3.14 on every push.

Benchmarks (recall quality, v0.6.0+)

"Best in class" is only worth saying if you can reproduce it. benchmarks/run_recall_bench.py spins up a real embedded YantrikDB, ingests a curated MIT-clean memory-QA corpus (benchmarks/dataset.json — 40 memories, 37 queries across preferences / architecture / people / work / infra), runs the real provider recall path, and scores it:

python benchmarks/run_recall_bench.py            # baseline
python benchmarks/run_recall_bench.py --reinforce  # + self-tuning lift

Current run (bundled potion-2M embedder, deterministic):

MRR 0.928. With --reinforce, reinforcing each query's gold memory lifts recall@1 to 0.865 and MRR to 0.928 — a measurable self-tuning gain that the loop produces on its own. tests/test_recall_benchmark.py asserts conservative floors so a ranking regression fails CI (it skips when the native engine wheel isn't installed). Extend the corpus to benchmark against your own data. Details: benchmarks/README.md.

Running the tests

python -m pytest tests/                          # unit tests
YANTRIKDB_INTEGRATION_URL=http://localhost:7438 \
YANTRIKDB_INTEGRATION_TOKEN=ydb_... \
  python -m pytest tests/integration/ -v         # live integration

Status

v0.4.2 (current) — first-class embedder loaders for the model2vec family and the HF sentence-transformers ecosystem; embedding dim auto-probed; default install stays slim via optional [model2vec] and [sentence-transformers] pip extras. 151 tests passing on Python 3.11/3.12/3.13. Standalone-by-design per Hermes maintainer guidance — Hermes is not accepting new memory providers upstream; standalone plugins installed via pip are the recommended pattern. PR #9989 closed 2026-05-13 with that resolution.

Release cadence

Durability signals

The maintainer doesn't promise "I won't quit" — promises like that aren't testable. What's testable:

• Every release ships with tests + CI (Python 3.11 / 3.12 / 3.13) + tagged CHANGELOG + a publish gate where 151 tests + ruff + mypy must pass before the wheel uploads to PyPI.
• First user issue on this repo (multilingual embedding support) was filed and shipped to PyPI the same day — 25 minutes from raised to released.
• Underlying yantrikdb engine: ~5.2k/mo PyPI downloads; flagship server repo has 141 GitHub stars; broader yantrikos namespace ~13.5k/mo combined PyPI+npm. Cross-stack ownership (engine + HTTP server + MCP server + this plugin) — 14+ months of parallel maintenance, not a one-week hobby.
• Independent recognition: accepted into the Cursor Directory (300k+ developer reach) and (sibling project) the Anthropic MCP Directory.
• Substrate design deposited as a peer-citable preprint: 10.5281/zenodo.20128887.

That's what I can give you. The technical merits are above; the maintenance shape is here so you can audit before adopting.

See yantrikdb/CHANGELOG.md for full release notes and yantrikdb/ARCHITECTURE.md for the control flow, error taxonomy, and threading model (covering both backends).

License

This plugin is MIT (matching Hermes — the code is intended for upstream contribution). The YantrikDB server itself is AGPL-3.0; the plugin only talks to it over HTTP and does not embed or redistribute any server code, so the boundary is the same as any MIT client talking to an AGPL service. See yantrikdb/SECURITY.md for the full note.

Links

• Plugin docs: yantrikdb/README.md
• Architecture: yantrikdb/ARCHITECTURE.md
• Verification transcripts: VERIFICATION.md
• Hermes Agent: https://github.com/NousResearch/hermes-agent
• YantrikDB server: https://github.com/yantrikos/yantrikdb-server
• YantrikDB docs: https://yantrikdb.com