Data

Tools

Indexes

Applications

Experiments

Awesome

An open API service indexing awesome lists of open source software.

https://github.com/yantrikos/yantrikdb-hermes-plugin

YantrikDB memory provider for NousResearch/hermes-agent — self-maintaining memory with canonicalization, contradiction tracking, recency ranking, and explainable recall.
https://github.com/yantrikos/yantrikdb-hermes-plugin

ai-memory hermes-agent knowledge-graph llm-agent memory plugin yantrikdb

Last synced: 15 days ago
JSON representation

YantrikDB memory provider for NousResearch/hermes-agent — self-maintaining memory with canonicalization, contradiction tracking, recency ranking, and explainable recall.

Awesome Lists containing this project

README 

          
# yantrikdb-hermes-plugin



[![CI](https://github.com/yantrikos/yantrikdb-hermes-plugin/actions/workflows/ci.yml/badge.svg)](https://github.com/yantrikos/yantrikdb-hermes-plugin/actions/workflows/ci.yml)

[![Tests](https://img.shields.io/badge/tests-128%20passing-brightgreen)](https://github.com/yantrikos/yantrikdb-hermes-plugin/actions)

[![Python](https://img.shields.io/badge/python-3.11%20%7C%203.12%20%7C%203.13%20%7C%203.14-blue)](https://github.com/yantrikos/yantrikdb-hermes-plugin)

[![License](https://img.shields.io/badge/license-MIT-blue)](LICENSE)

[![YantrikDB](https://img.shields.io/badge/yantrikdb-%E2%89%A50.7.6-orange)](https://github.com/yantrikos/yantrikdb-server)

[![Hermes Agent](https://img.shields.io/badge/hermes--agent-plugin-8a2be2)](https://github.com/NousResearch/hermes-agent)

[![Ruff](https://img.shields.io/endpoint?url=https://raw.githubusercontent.com/astral-sh/ruff/main/assets/badge/v2.json)](https://github.com/astral-sh/ruff)

[![mypy](https://img.shields.io/badge/mypy-checked-2a6db2)](https://mypy-lang.org/)



> **YantrikDB as a memory provider for [Hermes Agent](https://github.com/NousResearch/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](https://hermes-agent.nousresearch.com/docs/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](https://hermes-agent.nousresearch.com/docs/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



| Capability | yantrikdb-hermes-plugin | Most others |

|---|---|---|

| Agent-authored skills with outcome ledger (`yantrikdb_skill_define` / `_search` / `_outcome`) | ✓ first-class, DB-native peer to Hermes' filesystem Markdown skills | filesystem-only (Hermes built-in) |

| Contradiction tracking (`conflicts()` + `resolve_conflict()`) | ✓ first-class primitive | not in [mem0's 2026 taxonomy](https://docs.mem0.ai) |

| Explainable recall (`why_retrieved` per result) | ✓ list of scoring reasons returned with every result | rarely surfaced |

| Owner-scoping for multi-platform Hermes (Telegram + WhatsApp + Discord routed by canonical owner) | ✓ v0.4.10 identity-map + v0.4.11 shared group spaces | one shared namespace, manual scoping |

| Embedded mode default (no server, no token, no GPU) | ✓ v0.2.0+ | varies |

| HTTP backend for HA clusters | ✓ v0.5.0 (against yantrikdb-server) | varies |



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



![Constellation animation of the substrate growing](./assets/demos/skill-lifecycle/demo_visual.gif)



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`](./assets/demos/skill-lifecycle/demo_visual.py).



### What's actually running underneath



![LLM-driven skill lifecycle](./assets/demos/skill-lifecycle/demo_llm.gif)



`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`](./assets/demos/skill-lifecycle/demo_llm.py) + [`transcript-llm.txt`](./assets/demos/skill-lifecycle/transcript-llm.txt) + [`demo_llm.tape`](./assets/demos/skill-lifecycle/demo_llm.tape) for rendering. A scripted (no API key required) deterministic version is also included: [`demo.py`](./assets/demos/skill-lifecycle/demo.py) / [`demo.gif`](./assets/demos/skill-lifecycle/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/`](https://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)



```bash

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:



```bash

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

```



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



```bash

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:



```bash

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:



```bash

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:



```bash

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

```



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



```bash

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:



```bash

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:



```bash

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:



```bash

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:



```bash

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



```bash

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`:



```bash

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:



```bash

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 </`](tests/comparison/findings_scale_lxc/) — 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`](tests/comparison/README.md).



| Provider | Hosting | Verified at 1000 scale | Writes (ok/attempted; latency) | Recall latency | Precision@5 | `why_retrieved` field | Maintenance behaviour observed |

|---|---|---|---|---|---|---|---|

| **yantrikdb** (this) | embedded | yes — 256/1000 writes [^queuecap] | 256/1000; p50 0.48 ms / p99 5.13 ms | p50 3.78 ms / p99 32.94 ms | **0.80** (16/20) | yes — `why_retrieved` per result | contradiction API: `yantrikdb_conflicts`; duplicates kept separate (canonicalisation via explicit `think()`) |

| [byterover](https://github.com/NousResearch/hermes-agent/tree/main/plugins/memory/byterover) | cloud | couldn't verify — requires `brv` CLI auth | — | — | — | — | — |

| [hindsight](https://github.com/NousResearch/hermes-agent/tree/main/plugins/memory/hindsight) | cloud-default (local-stub mode used) | yes — 1000/1000 writes | 1000/1000; p50 0.27 ms / p99 0.31 ms | p50 0.28 ms / p99 0.30 ms | **0.00** (0/20) [^localstub] | no | — |

| [holographic](https://github.com/NousResearch/hermes-agent/tree/main/plugins/memory/holographic) | embedded (SQLite + FTS5) | yes — 1000/1000 writes [^hrrcap] | 1000/1000; p50 23.43 ms / p99 68.52 ms | p50 0.06 ms / p99 0.23 ms | **0.00** (0/20) [^keyword] | no | — |

| [honcho](https://github.com/NousResearch/hermes-agent/tree/main/plugins/memory/honcho) | self-hosted | couldn't verify — requires honcho-server URL or api key | — | — | — | — | — |

| [mem0](https://github.com/NousResearch/hermes-agent/tree/main/plugins/memory/mem0) | cloud or self-host | couldn't verify — requires `mem0.api_key` | — | — | — | — | — |

| [openviking](https://github.com/NousResearch/hermes-agent/tree/main/plugins/memory/openviking) | self-hosted | couldn't verify — requires `OPENVIKING_ENDPOINT` | — | — | — | — | — |

| [retaindb](https://github.com/NousResearch/hermes-agent/tree/main/plugins/memory/retaindb) | cloud | couldn't verify — requires `RETAINDB_API_KEY` | — | — | — | — | — |

| [supermemory](https://github.com/NousResearch/hermes-agent/tree/main/plugins/memory/supermemory) | cloud | couldn't verify — requires `SUPERMEMORY_API_KEY` | — | — | — | — | — |



[^queuecap]: yantrikdb v0.4.2 plugin against yantrikdb engine 0.7.8 on Linux: the engine's ingest queue is bounded at 256 pending ops and didn't drain during the 1000-fact burst (probe hit `RuntimeError('ingest queue full ...; retry after 50ms')` from fact 257 onward, even with 60-attempt × 100 ms backoff). Recall on the 256 stored facts is solid (P@5 = 0.80). Surfaced upstream as a likely queue-drain regression in the manylinux build of 0.7.8 — the Hermes plugin itself doesn't loop the writes.



[^localstub]: `HINDSIGHT_MODE=local_embedded` was set so `is_available()` returns true without an API key, but in this configuration writes return immediately (sub-millisecond) and recall returns no results — the local mode appears to be a no-op stub rather than a real local backend. Full retrieval almost certainly requires the cloud account.



[^hrrcap]: At ~256 stored items, the engine emits `HRR storage near capacity: SNR=2.00 (dim=1024, n_items=...)` warnings on every subsequent write. The capacity warning is part of holographic's normal output; it's not an error and writes continue to succeed, but retrieval quality is expected to degrade past that point.



[^keyword]: Holographic's recall is keyword-based (FTS5 + HRR cleanup); the probe's queries are full sentences (`"What color scheme does the user prefer in VS Code?"`). The 0/20 result is a query-format mismatch, not a retrieval failure — keyword-shaped queries probably hit. The honest takeaway is that holographic and yantrikdb target different query shapes, not that one is "better".



**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`](tests/comparison/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:



```bash

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

```



When enabled, three new tools join the schema:



| Tool | Purpose |

|---|---|

| `yantrikdb_skill_search` | Semantic search over agent-authored skills, namespace-isolated from regular memory recall. |

| `yantrikdb_skill_define` | Distill a procedural pattern into a reusable skill (`skill_id`, `body`, `skill_type`, `applies_to`). Client-side validation reproduces yantrikdb-server's wrapper checks. |

| `yantrikdb_skill_outcome` | Record success/failure for a skill after it's used. Append-only event log; rollup is the agent's call, not the substrate's. |



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](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)



| Op | v0.1 HTTP (Apr 14) | v0.2 Embedded (May 9) |

|---|---|---|

| `record_text` p50 | 13.8 ms | **0.60 ms** |

| `recall_text` p50 | 24.0 ms | **2.58 ms** |

| `record_text` p99 | 55.3 ms | 10.66 ms |

| `recall_text` p99 | 67.2 ms | 13.24 ms |

| Cold start | n/a | 77 ms (one-time) |

| Required infrastructure | yantrikdb-server + token | none |

| `pip install` footprint | wheel + requests | wheel + 2 small libs (~10 MB total) |



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](https://github.com/yantrikos/yantrikdb)); 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`](https://huggingface.co/minishlab/potion-base-2M) via [`model2vec-rs`](https://github.com/MinishLab/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](https://github.com/yantrikos/yantrikdb/blob/main/scratch/eval_potion_2m.py).** 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.



## Running the tests



```bash

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](https://github.com/NousResearch/hermes-agent/pull/9989) closed 2026-05-13 with that resolution.



### Release cadence



| Version | Date | Highlight |

|---|---|---|

| v0.1.0 | 2026-04-14 | HTTP backend, 8 tools, 96 tests |

| v0.2.0 | 2026-05-09 | Embedded backend default, ~10 MB install, sub-ms recall |

| v0.3.0 | 2026-05-09 | Skill substrate bridge (opt-in) |

| v0.3.1 | 2026-05-09 | PyPI distribution + `yantrikdb-hermes` CLI installer |

| v0.4.1 | 2026-05-12 | Pluggable embedders (custom Python class via `YANTRIKDB_EMBEDDER_CLASS`) |

| v0.4.2 | 2026-05-12 | First-class `model2vec` + `sentence-transformers` loaders, auto-probed dim |



### 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](https://cursor.directory/plugins/yantrikdb) (300k+ developer reach) and (sibling project) the Anthropic MCP Directory.

- Substrate design deposited as a peer-citable preprint: [10.5281/zenodo.20128887](https://doi.org/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](yantrikdb/CHANGELOG.md) for full release notes and [yantrikdb/ARCHITECTURE.md](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](https://github.com/yantrikos/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](yantrikdb/SECURITY.md#license-boundary-agpl-vs-mit) for the full note.



## Links



- **Plugin docs**: [yantrikdb/README.md](yantrikdb/README.md)

- **Architecture**: [yantrikdb/ARCHITECTURE.md](yantrikdb/ARCHITECTURE.md)

- **Verification transcripts**: [VERIFICATION.md](VERIFICATION.md)

- **Hermes Agent**: 

- **YantrikDB server**: 

- **YantrikDB docs**: