Persistent memory (YantrikDB)

SkillDocs & knowledge

Give this agent durable memory across sessions using YantrikDB. Use at the start of every session to load prior context, whenever the user or a job references past decisions, people, preferences, or earlier runs, and whenever something worth keeping is learned (a decision, a fact, a working method, a qualified lead, a benchmark result). Requires the yantrikdb MCP server to be connected.

Available today. Use it from your connected AI after setup.

Connect ahel once, and every AI you use reads what you have installed.

Then ask your AI: use the Persistent memory (YantrikDB) skill

What this skill tells your AI

The instructions your AI receives, as published by yantrikos/yantrikdb-mcp in skills/persistent-memory/SKILL.md and read by ahel’s review.

You have a persistent, semantic, typed memory that survives across sessions, provided by the yantrikdb MCP server. It is not a notes file: it does similarity recall, tracks belief revisions, detects contradictions, learns procedures, and answers "what did I believe at time t". Treat it as your long-term memory, not as optional tooling.

Tool names may carry a harness prefix (mcp_yantrikdb_recall, mcp__yantrikdb__recall, or bare recall). The unprefixed names are used below; map them to whatever your harness registered.

Session start — one call

Call session with action="digest" once. It returns a single briefing: narrative head, open decisions, unresolved conflicts, pending triggers, and stale high-importance memories. Do this before answering anything substantive; a session that starts blank when 500 memories exist is a bug, and it is this one.

Before acting — recall, the right way

  • Query with one short natural-language sentence (5–10 words), not a keyword list. Separate focused calls beat one broad one.
  • For "what is the CURRENT value of X" (latest config, current owner, present status), use memory with action="chain_head" — similarity search returns the most-similar revision, which for values that change over time is often stale. chain_head returns the actual current value.
  • Trust signals: hits whose why_retrieved says "aged", "superseded", or "rarely confirmed" are weak evidence. Prefer fresher hits, and say so if you act on a flagged one.
  • Before starting a task you may have done before, call procedure with action="surface" — a learned method beats re-deriving one.

During work — capture as you go

  • New durable fact → remember. Be specific and searchable ("Client Foo approved the March pricing tier", not "they said yes"). Set importance: 0.8–1.0 decisions and hard commitments, 0.5–0.7 useful context, 0.3–0.5 background. Set domain and source.
  • A stored fact changedcorrect with a reason — never a second remember. This preserves history and prevents the contradiction the next session would otherwise inherit.
  • Entity relationship learned → graph with action="relate".
  • A working method discovered (a scraping recipe that got past a blocker, a benchmark invocation that finally worked) → procedure with action="learn".
  • Do NOT store: secrets or credentials, ephemeral task chatter, anything derivable from the repo or files you already have. Memory is for what would otherwise be lost when this session ends.

Job and pipeline agents — the operator patterns

If you are a recurring job (scraper, lead-gen, benchmark, monitor) rather than a chat companion:

  • Namespace per pipeline. Pass namespace="<pipeline-name>" on every call so runs of different jobs never pollute each other's recall.
  • Exactly-once on retries. Harness retries duplicate writes. Pass idempotency_key on remember — same key + same text returns the same record instead of writing twice.
  • Dedupe against prior runs. Before processing an item (a lead, a URL, a test case), recall it. Already stored with the same outcome → skip. This is what makes run #50 cheaper than run #1 instead of identical to it.
  • Store outcomes, not transcripts. "example.com qualified: 200-seat firm, hiring for data roles" is a memory. The raw scraped HTML is not.
  • Resurface on schedule. Use trigger to have a memory come back at a time or on a condition ("re-check this lead in two weeks") instead of hoping a future run thinks of it.

End of substantial work — conditional

Only when the session was long or changed real state: call think to consolidate and surface contradictions. If it reports conflicts, resolve them with conflict action="resolve" or ask the user — do not leave a contradiction for the next session to trip over. Short read-only sessions skip this.

The habit that makes it work

Every substantive turn either reads from memory (recall) or writes to it (remember). A turn that does neither leaves no trace, and the next session starts closer to blank than it should. If you notice three substantive turns without touching memory, pause and recall.

Signals

GitHub stars
24
Forks
7
Last commit
Sep 2026
Advanced
Catalog kind
skill
Gateway key
persistent-memory-yantrikos
Source
github.com/yantrikos/yantrikdb-mcp