agentleFS
yantrikosyantrikos/yantrikdb-mcp/skills/persistent-memory/SKILL.md

persistent-memory

Skill24 starsChanged 10 days agoMITView on GitHub

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.

8 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

8 rules. 0 are common, 3 are distinctive, and 5 are very specific to this project.

  • 0

    Common

    Most of the 7 edited versions we read keep these.

  • 3

    Distinctive

    This author's own choices. Worth a look.

  • 5

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Call session with action="digest" once.

    line 31
  2. Very specific:

    Before starting a task you may have done before, call procedure with action="surface" — a learned method beats re-deriving one.

    line 48
  3. Distinctive:

    Do NOT store: secrets or credentials, ephemeral task chatter, anything derivable from the repo or files you already have.

    line 64
  4. Distinctive:

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

    line 70
  5. Very specific:

    Dedupe against prior runs: Before processing an item (a lead, a URL, a test case), recall it.

    line 78
  6. Very specific:

    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 …

    line 83
  7. Very specific:

    Only when the session was long or changed real state: call think to consolidate and surface contradictions.

    line 89
  8. Distinctive:

    Every substantive turn either reads from memory (recall) or writes to it (remember).

    line 97

“Common” is measured: kept by at least 6 in 10 of the 7 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.