Lore
Documentation navigation
Docs/Concepts/Recall

Recall

Understand how Lore retrieves task-relevant memory candidates and why agents should open nodes before relying on them.

Recall finds memories related to the current task and presents them as candidates.

How recall chooses candidates

Recall combines several signals: text search over memory content and generated views, glossary matching, disclosure triggers, priority, and semantic retrieval when embeddings are configured. The exact candidate list depends on settings and available database extensions.

Recall block format

A recall block in an agent prompt looks like:

*.txt
Plaintext
<recall session_id="sess-1" query_id="q1">
0.74 | preferences://user | concise replies · timezone
0.68 | project://my_app/deployment | cloudflare pages · build command
</recall>

Each line shows a score, a memory URI, and the terms that matched. The score is a relevance signal, not a command — always open the node before relying on it.

How to use recall

  1. Read the recall block.
  2. Open the relevant memory nodes with lore_get_node (pass the session_id and query_id so Lore tracks usage).
  3. Ignore weak or unrelated candidates.
  4. Improve memory shape when the same useful memory is missing repeatedly.

Do not tune recall thresholds before checking whether the memory has good disclosure, glossary, and priority.

What Lore is forLearn which facts, preferences, decisions, and rules should become durable memory.How Lore worksUnderstand the loop: boot context, recall, reading memories, writing durable changes, and review.When to use itDecide which information is worth saving and which short-lived notes can stay out of memory.Memory modelLearn the core memory shape: paths, domains, priority, disclosure, glossary terms, and generated views.