Persistent memory (YantrikDB)
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 changed →
correct 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.
1---2name: persistent-memory3description: 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.4license: MIT5---67# Persistent memory (YantrikDB)89You have a persistent, semantic, typed memory that survives across sessions,10provided by the `yantrikdb` MCP server. It is not a notes file: it does11similarity recall, tracks belief revisions, detects contradictions, learns12procedures, and answers "what did I believe at time t". Treat it as your13long-term memory, not as optional tooling.1415Tool names may carry a harness prefix (`mcp_yantrikdb_recall`,16`mcp__yantrikdb__recall`, or bare `recall`). The unprefixed names are used17below; map them to whatever your harness registered.1819## Session start — one call2021Call `session` with `action="digest"` once. It returns a single briefing:22narrative head, open decisions, unresolved conflicts, pending triggers, and23stale high-importance memories. Do this before answering anything24substantive; a session that starts blank when 500 memories exist is a bug,25and it is this one.2627## Before acting — recall, the right way2829- Query with **one short natural-language sentence** (5–10 words), not a30 keyword list. Separate focused calls beat one broad one.31- For "what is the CURRENT value of X" (latest config, current owner, present32 status), use `memory` with `action="chain_head"` — similarity search33 returns the most-similar *revision*, which for values that change over time34 is often stale. `chain_head` returns the actual current value.35- Trust signals: hits whose `why_retrieved` says "aged", "superseded", or36 "rarely confirmed" are weak evidence. Prefer fresher hits, and say so if37 you act on a flagged one.38- Before starting a task you may have done before, call `procedure` with39 `action="surface"` — a learned method beats re-deriving one.4041## During work — capture as you go4243- New durable fact → `remember`. Be specific and searchable ("Client Foo44 approved the March pricing tier", not "they said yes"). Set `importance`:45 0.8–1.0 decisions and hard commitments, 0.5–0.7 useful context, 0.3–0.546 background. Set `domain` and `source`.47- A stored fact **changed** → `correct` with a `reason` — never a second48 `remember`. This preserves history and prevents the contradiction the next49 session would otherwise inherit.50- Entity relationship learned → `graph` with `action="relate"`.51- A working method discovered (a scraping recipe that got past a blocker, a52 benchmark invocation that finally worked) → `procedure` with53 `action="learn"`.54- Do NOT store: secrets or credentials, ephemeral task chatter, anything55 derivable from the repo or files you already have. Memory is for what56 would otherwise be lost when this session ends.5758## Job and pipeline agents — the operator patterns5960If you are a recurring job (scraper, lead-gen, benchmark, monitor) rather61than a chat companion:6263- **Namespace per pipeline.** Pass `namespace="<pipeline-name>"` on every64 call so runs of different jobs never pollute each other's recall.65- **Exactly-once on retries.** Harness retries duplicate writes. Pass66 `idempotency_key` on `remember` — same key + same text returns the same67 record instead of writing twice.68- **Dedupe against prior runs.** Before processing an item (a lead, a URL, a69 test case), `recall` it. Already stored with the same outcome → skip. This70 is what makes run #50 cheaper than run #1 instead of identical to it.71- **Store outcomes, not transcripts.** "example.com qualified: 200-seat firm,72 hiring for data roles" is a memory. The raw scraped HTML is not.73- **Resurface on schedule.** Use `trigger` to have a memory come back at a74 time or on a condition ("re-check this lead in two weeks") instead of75 hoping a future run thinks of it.7677## End of substantial work — conditional7879Only when the session was long or changed real state: call `think` to80consolidate and surface contradictions. If it reports conflicts, resolve them81with `conflict` `action="resolve"` or ask the user — do not leave a82contradiction for the next session to trip over. Short read-only sessions83skip this.8485## The habit that makes it work8687Every substantive turn either **reads from** memory (recall) or **writes88to** it (remember). A turn that does neither leaves no trace, and the next89session starts closer to blank than it should. If you notice three90substantive turns without touching memory, pause and recall.