Resonance-weighted recall

Subtitle: A technical whitepaper on source-aware, experience-weighted memory retrieval for persistent LLM agents

Status: Technical whitepaper draft
Date: 2026-06-21
Author: Clint Bodungen
Project context: MindStone Agent, MindStone-Agent, MS4CC, MS4PI
Companion to: Layered Continuity Architecture for Persistent LLM Agents

Executive summary

Most LLM memory systems start with retrieval: take the current prompt, search stored records, and inject the most similar results. That is useful, but it is not enough for a persistent agent.

A long-running agent needs to recall not only what is textually similar, but what matters in the current operational context. A user correction from a month ago may be more important than a semantically closer note from yesterday. A safety constraint may be relevant even when it shares few words with the current prompt. A project decision in a structured memory file may deserve more trust than a loose transcript fragment. A private preference may be relevant but unsafe to expose in a shared channel.

Resonance-weighted recall is MindStone’s answer to that problem.

It is a recall strategy that ranks candidate memories by multiple signals:

semantic similarity;
source authority;
memory kind;
task and role relevance;
recency and half-life;
prior usefulness;
critical or evergreen status;
duplicate status;
privacy, safety, and conflict risk.

The goal is not to make recall mystical or opaque. The goal is to make retrieval behave more like operational memory: the right past experience returns because it fits the current task, role, source context, and risk boundary — not merely because the words are close in an embedding space.

In MindStone, resonance-weighted recall is part of the Auto Recall layer. It runs before inference, selects a bounded set of source-aware memory hits, injects them ephemerally into the current model call, and records compact diagnostics in the transcript. The recalled text does not become permanent standing context. The next turn recomputes recall from scratch.

The core principle:

Similarity finds candidates.
Resonance decides what deserves attention.

1. Problem statement

Persistent agents need memory, but “memory” is often reduced to vector search.

A typical retrieval-augmented generation flow looks like this:

current prompt
→ embedding search
→ top-k similar chunks
→ inject chunks into prompt
→ model response

This works well when the task is document lookup. It is weaker when the task is continuity.

A persistent agent needs to answer questions like:

What did the user correct me about before?
Which prior decision constrains this task?
Which memory is authoritative when two sources conflict?
What should I remember in this role but not in another?
What private context is unsafe to use in a public channel?
What old lesson prevents me from repeating a mistake?
Which recalled item is already present in active context and should not be duplicated?
Which memory is stale, superseded, or low-confidence?

Plain semantic similarity does not answer those questions.

A semantically close chunk can be irrelevant. A semantically distant instruction can be critical. A recent transcript fragment may be less reliable than an approved memory file. A frequently useful safety rule may deserve a boost. A sensitive user fact may deserve suppression in a shared channel.

Resonance-weighted recall adds those missing dimensions.

2. What resonance-weighted recall means

Resonance-weighted recall is a ranking and selection process for memory candidates.

It begins with retrieval, but it does not stop there.

A simple retrieval system asks:

Which stored chunks are closest to this query?

A resonance-weighted system asks:

Which stored chunks are most useful, trustworthy, safe, and relevant for this agent in this situation?

That distinction matters.

In MindStone, a memory can “resonate” because it is:

semantically related to the current prompt;
from a more authoritative source;
marked critical or evergreen;
recently created or recently applied;
repeatedly useful in prior work;
tied to the active project or role;
a known guardrail against previous mistakes;
not already present in the current prompt;
safe to expose in the current channel.

The output of resonance-weighted recall is not a permanent change to memory. It is a temporary context injection for the current turn.

Recall is ephemeral.
Memory is durable.
Transcript is authoritative.

3. Where it sits in Layered Continuity Architecture

Resonance-weighted recall is the indexed recall layer in MindStone’s Layered Continuity Architecture.

It sits between durable sources and the live prompt:

structured memory files
journals
LOG entries
transcripts
project docs
        ↓
indexing / embedding / lexical retrieval
        ↓
resonance-weighted ranking
        ↓
ephemeral recall injection
        ↓
current model inference

It works with, not instead of, the other layers:

Identity and user context define standing orientation.
Transcript history preserves the authoritative record.
Structured memory stores curated durable facts and decisions.
Journals preserve experiential narrative texture.
Sliding-window context management bounds the live prompt.
Resonance-weighted recall brings back relevant older material.
Handoff helps future agent states resume work.
Consolidation cycles convert experience into durable memory and maintain indexes.

This matters because recall cannot carry the whole continuity burden. Vectors are not truth. Similarity is not judgment. A recall result is context, not unquestioned authority.

MindStone recall prompts should make that explicit:

Relevant MindStone memory follows. Use it as context, not as unquestioned truth.
If it conflicts with current user instructions or local evidence, prefer current verified evidence.

4. Comparison with common recall methods

4.1 Keyword search

Keyword search retrieves documents that share exact or near-exact terms with the query.

Strengths:

simple;
fast;
explainable;
good for exact names, identifiers, paths, commands, and error strings;
does not require embedding infrastructure.

Weaknesses:

misses paraphrases;
struggles with conceptual similarity;
does not understand source authority;
does not know whether a result is stale, private, or already active.

MindStone still uses lexical fallback paths because they are robust and useful. But keyword search alone is not enough for continuity.

4.2 Vector similarity search

Vector search embeds queries and documents into a semantic space, then retrieves nearby chunks.

Strengths:

finds paraphrases and conceptual matches;
works across varied wording;
useful for large transcript and memory collections;
strong baseline for recall.

Weaknesses:

similarity is not authority;
similarity is not safety;
similarity is not freshness;
similar chunks can be redundant;
vector spaces can break when embedding providers change;
raw top-k retrieval can over-inject low-value context.

Resonance-weighted recall uses vector similarity as a provider score, not as the final answer.

Vector search proposes.
Resonance ranking disposes.

4.3 Hybrid search

Hybrid search combines lexical and semantic retrieval, often with reranking.

Strengths:

better coverage than either keyword or vector alone;
handles exact identifiers and conceptual matches;
can improve recall quality in document search systems.

Weaknesses:

still usually ranks by query-document relevance;
often lacks durable memory semantics;
usually does not encode agent-specific experience;
may not distinguish transcript fragments from approved memories;
may not account for privacy/channel policy.

Resonance-weighted recall can use hybrid search as a candidate provider, but adds an agent-continuity scoring layer above it.

4.4 Recency-based memory

Some systems prioritize recent messages or recent memories.

Strengths:

simple;
often useful in active tasks;
reflects the fact that recent context frequently matters.

Weaknesses:

old decisions can remain binding;
old corrections can prevent repeated mistakes;
foundational identity and safety rules should not decay like routine chatter;
recency alone can bury durable knowledge.

MindStone treats recency as a boost, not a filter. Memory files can include half-life metadata so different memory types decay differently.

4.5 Summaries as memory

Some systems periodically summarize conversation history and retrieve from those summaries.

Strengths:

compact;
cheaper than storing/retrieving full transcript chunks;
useful for quick state recovery.

Weaknesses:

summaries are lossy;
source texture disappears;
uncertainty may be flattened;
user corrections can be omitted;
summaries can become false authority;
repeated summarization can drift.

MindStone can use summaries and handoffs, but they are not the authoritative record. Recall should preserve source pointers and distinguish memory files, journals, logs, summaries, and raw transcript chunks.

4.6 Agent “memory” fields or profile blobs

Some assistants maintain a profile-like memory store: facts about the user, preferences, or persistent notes.

Strengths:

useful for stable preferences;
easy to inspect;
can improve personalization.

Weaknesses:

often too flat;
weak provenance;
weak lifecycle management;
poor fit for project decisions, incident histories, or operational lessons;
can become bloated standing context.

MindStone uses structured memory files, but does not treat a single profile blob as the whole memory system. Recall spans structured memories, journals, LOG entries, transcripts, and other source-aware records.

4.7 How resonance-weighted recall differs

Resonance-weighted recall is not a replacement for keyword search, vector search, hybrid retrieval, summaries, or profiles. It is a scoring layer that makes those sources useful for persistent-agent continuity.

The difference is the question being optimized.

Most retrieval systems optimize:

Which chunks match the query?

MindStone optimizes:

Which source-backed memories should shape this agent’s next response in this context?

5. Scoring model

A general resonance score can be represented as:

R(m, c) = αS(m, c) + βE(m) + γT(m) + δA(m) + εQ(m, c) - λK(m, c)

Where:

m is a memory candidate;
c is the current context;
S is semantic similarity;
E is experiential weight;
T is temporal salience;
A is source authority;
Q is task/role relevance;
K is risk, conflict, or safety penalty;
coefficients control the relative influence of each signal.

This formula is not the product. It is a design model.

The important idea is dimensional separation. Do not hide every decision inside a single similarity score.

5.1 Semantic similarity

Semantic similarity is the baseline provider score.

Possible providers:

lexical score;
embedding cosine similarity;
sqlite-vec nearest neighbor search;
JS cosine fallback over stored vectors;
external vector database;
hybrid search provider;
future reranker.

MindStone-Agent currently supports lexical recall, SQLite-indexed memory, embedding-backed recall over SQLite-stored vectors with JS cosine fallback, and explicit reporting when native sqlite-vec search is unavailable.

5.2 Source authority

Different sources deserve different authority.

A structured memory file approved during checkpoint may be more authoritative than an unreviewed transcript fragment. A raw transcript may be more authoritative than a summary when exact wording matters. A current project file may supersede older memory.

Useful source classes include:

identity
structured memory
reference document
detection / incident / case memory
journal
checkpoint / LOG entry
transcript chunk
index pointer
summary / handoff

Authority does not mean “always trust this.” It means the ranker should know what kind of source it is using.

5.3 Experiential weight

Experiential weight captures whether a memory has proven useful or important over time.

Signals can include:

hit count;
prevented-mistake count;
explicit user correction;
checkpoint promotion;
recurring task relevance;
major project outcome;
high-trust approval;
role-critical use.

Experiential weight should be bounded. Otherwise, frequently recalled memory can dominate even when it is not relevant.

Good rule:

Experiential weight modifies plausible candidates.
It should not make irrelevant candidates win by itself.

5.4 Recency and half-life

Recency matters, but different memory types should decay differently.

A daily task note may have a short half-life. A project architecture decision may have a long half-life. A safety rule may be evergreen.

MindStone-style memory frontmatter can support this:

hits: 0
prevented: 0
last_applied: null
created: 2026-06-21
half_life_days: 30
critical: false
evergreen: true

The ranker can apply a decaying boost based on age and half-life rather than treating every old memory as stale.

5.5 Critical and evergreen status

Some memories should remain more visible because they represent stable constraints.

Examples:

“Do not disclose sensitive local context.”
“Do not claim live validation is complete until tested.”
“This project uses canonical session key agent:default:main.”
“Cortex must not be described as public-internet safe without auth.”

Critical and evergreen flags should boost recall, but still respect relevance and channel safety.

5.6 Task and role relevance

The same prompt can require different recall depending on role.

A software-engineering role might need implementation memories. A product-writing task might need positioning decisions. A SOC role might need incident and detection memories. A public-channel response might need privacy filtering.

Task relevance can be inferred from:

active role;
current project path;
channel or surface;
selected skill;
route/session metadata;
explicit user instruction;
recent transcript context.

5.7 Risk and conflict penalty

A recall system should not only maximize usefulness. It should reduce harm.

Candidates may need suppression or demotion when they are:

private in a public channel;
stale or superseded;
contradicted by newer local evidence;
sourced from a low-authority summary;
outside the active role’s scope;
likely to expose secrets;
already present in the active prompt;
duplicative of another selected hit.

Risk penalty is what keeps recall from becoming indiscriminate prompt stuffing.

6. Current MindStone-Agent implementation pattern

Current MindStone-Agent code implements a first-pass version of resonance-weighted recall.

Older/internal implementation names may still reference SCRI-style ranking. This paper uses the public-facing term resonance-weighted recall for the broader design.

6.1 Candidate providers

MindStone-Agent can discover and index:

structured memory files;
memory/MEMORY.md;
journals;
LOG.md;
JSONL transcript entries.

Implemented commands include:

mindstone memory backfill
mindstone memory status
mindstone memory backfill --embed
mindstone memory maintain
mindstone memory backfill --maintain --dedupe-text
mindstone memory status --json
mindstone memory backfill --json
mindstone memory maintain --json

Embedding-backed recall uses an OpenAI-compatible embedding interface, with an Ollama-style local default such as:

ollama:nomic-embed-text
http://127.0.0.1:11434/v1

Native sqlite-vec nearest-neighbor search is planned, but current local fallback may use JS cosine or lexical search depending on available embeddings and sqlite-vec support.

6.2 Ranking signals currently implemented

The current first-pass ranker includes:

provider score;
memory kind boost;
source path boost;
critical boost;
evergreen boost;
usage boost from hits and prevented metadata;
recency boost using created, last_applied, or timestamp;
half-life-aware decay;
duplicate-active-context rejection;
duplicate-candidate rejection;
score diagnostics.

A simplified current scoring shape:

finalScore = providerScore * 0.78
           + kindBoost
           + sourceBoost
           + criticalBoost
           + evergreenBoost
           + usageBoost
           + recencyBoost

Then scores are clamped to a normalized range and sorted.

This is intentionally practical rather than final. Weight tuning against real traces remains pending.

6.3 Source and kind boosts

The current ranker gives different boosts to different memory kinds.

Examples:

identity      high boost
custom/doc    high boost
journal       moderate boost
checkpoint    moderate boost
log           lower boost
transcript    lower boost
index         low boost

Structured memory paths also receive a source boost, especially files such as:

memory/project_*.md
memory/design_*.md
memory/reference_*.md
memory/detection_*.md
memory/incident_*.md
memory/case_*.md
memory/feedback_*.md

The purpose is not to bury transcripts. Transcript chunks are valuable. But when a curated structured memory and a loose transcript fragment both match, the structured memory often deserves higher initial authority.

6.4 Deduplication

Recall should not waste budget repeating what is already visible.

MindStone-Agent currently deduplicates against:

active prompt/session context;
already selected candidate chunks;
highly similar candidate text signatures.

Rejected candidates are recorded in diagnostics with reasons such as:

duplicate-active-context
duplicate-candidate

This matters because recall budget is small. Injecting duplicate context reduces the chance that genuinely useful older material can return.

6.5 Prompt injection

Selected recall hits are formatted into an ephemeral context block for the current model call.

The block includes:

a caution that memory is context, not unquestioned truth;
the hit title/path/id;
final resonance score;
provider score where available;
ranking reasons;
selected text.

The recall block is not appended to standing context. It is not automatically promoted to durable memory. It is not assumed to be correct if it conflicts with current evidence.

6.6 Transcript diagnostics

MindStone-Agent records compact recall diagnostics in transcript events, including counts such as:

rawHitCount
rankedHitCount
selectedHitCount
rejected[]

This makes recall auditable without permanently stuffing the full recalled text into every future prompt.

7. Auto Recall flow

MindStone Auto Recall is designed to run before inference.

A typical flow:

1. User submits prompt.
2. System appends/observes prompt in session context.
3. Recall query is built from recent user/task context.
4. Candidate provider searches memory/transcript/journal sources.
5. Low-score candidates are filtered.
6. Resonance-weighted ranking is applied.
7. Active-context duplicates are rejected.
8. Candidate duplicates are rejected.
9. Top hits are selected within max result and token budgets.
10. Ephemeral recall block is injected into the current model call.
11. Compact recall diagnostics are recorded.
12. Model answers with relevant past context already present.

This differs from manual memory search.

Manual search is deliberate:

The agent decides to search memory.

Auto Recall is substrate behavior:

Relevant memory is prepared before the agent answers.

The agent may or may not be aware that recall happened, depending on how the prompt is assembled. The important property is that the past can shape the next response without requiring the agent to remember to search.

8. Integration with sliding-window context management

Sliding windows and resonance-weighted recall are complementary.

Sliding-window context management says:

The live prompt cannot contain everything forever.

Resonance-weighted recall says:

The right older material can return when it matters.

Without recall, sliding-window pruning becomes truncation. Without sliding-window pruning, recall competes with an ever-growing prompt and the system eventually hits context pressure.

The combined behavior is:

1. Preserve full transcript.
2. Keep active prompt bounded.
3. Let old material leave the prompt safely.
4. Index and rank preserved material.
5. Reinject relevant memory when needed.

This is the core mechanism that lets MindStone preserve continuity without keeping all history in the model’s immediate context.

9. Integration with structured memory, journals, and LOG

MindStone recall works best when sources have different roles.

9.1 Structured memory files

Structured memory files preserve durable, reusable facts:

project decisions;
design constraints;
user preferences;
safety rules;
incident/case records;
detection notes;
reference facts.

These are usually higher-authority recall sources because they are curated.

9.2 Journals

Journals preserve narrative texture:

what unfolded;
what was surprising;
what mistakes or near misses happened;
what patterns emerged;
what context would be lost in a bullet summary.

Journals are valuable because embeddings over narrative often preserve associative texture that structured facts miss.

9.3 LOG entries

LOG.md is an operational ledger:

checkpoint entries;
decisions made;
work completed;
drift flagged;
verification status;
memory changes.

LOG is not the whole memory store, but it is useful for timeline and checkpoint recall.

9.4 Transcripts

Transcripts preserve the full operational record.

They are especially important when:

exact wording matters;
summaries disagree;
source provenance is needed;
the agent must recover context not promoted to memory;
a checkpoint or consolidation cycle needs evidence.

Transcript recall may receive less source-authority boost than curated memory, but transcript remains the ultimate historical record.

10. Privacy and safety model

A powerful recall system can surface the wrong thing in the wrong place.

Resonance-weighted recall therefore needs channel and policy awareness.

Risk-sensitive examples:

private user facts in public or shared channels;
credentials or secrets;
sensitive internal workplace context;
personal relationship details;
stale facts superseded by newer records;
unverified claims from transcript fragments;
source material outside the active role’s authority.

A safe recall pipeline should support:

source metadata;
channel classification;
sensitivity tags;
risk penalties;
hard filters for secrets;
“use privately, do not disclose” behavior;
audit diagnostics.

Important distinction:

A memory can be relevant and still unsafe to use directly.

Recall should not be optimized only for relevance. It must also be optimized for appropriate use.

11. Operational guidance

11.1 Keep recall ephemeral

Auto Recall should behave like a fleeting thought, not a permanent mood.

Inject it into the current model call only. Recompute it next turn.

Do not append every recall block to standing context.

11.2 Keep budgets strict

Recall should have a token budget.

Useful controls:

maxResults
maxPromptTokens
minScore
maxActiveEntriesForDedup

A small number of high-value hits is usually better than flooding the prompt with every plausible match.

11.3 Keep source pointers

Recall without source pointers becomes unaccountable prompt stuffing.

Every hit should preserve:

source id
path
title
kind
chunk id
score
ranking reasons
metadata

When a response depends on recalled memory, the agent should be able to distinguish memory from local evidence and inference.

11.4 Prefer current verified evidence over memory

Memory can be stale.

The model should be instructed that recalled context is useful but not unquestioned truth. Current local evidence, direct user instruction, and verified source files can supersede recalled memory.

11.5 Maintain the index

Recall quality depends on index health.

MindStone-Agent includes first-pass SQLite maintenance:

stale source cleanup;
exact-text dedupe;
empty/orphan source cleanup;
SQLite optimize/reindex/VACUUM/WAL checkpoint;
bloat diagnostics;
JSON output for automation;
preservation of unchanged embeddings during backfill.

This matters because append-only memory without maintenance can become slow, duplicate-heavy, and unreliable.

11.6 Do not confuse recall with memory writing

A recalled item appearing in prompt does not make it durable memory.

Durable memory should be written through checkpoint or consolidation flows, with source review and approval where appropriate.

12. Failure modes and safeguards

12.1 Similarity trap

A semantically close result can be the wrong memory.

Safeguard:

Use similarity as one signal, not the whole ranking.

12.2 Authority inversion

A loose transcript fragment can outrank an approved memory if raw similarity dominates.

Safeguard:

Add source authority and kind boosts.

12.3 Memory echo

A memory already present in the prompt gets recalled again, wasting budget and reinforcing itself.

Safeguard:

Deduplicate against active context.

12.4 Stale belief reinforcement

Old memories can keep resurfacing after they are superseded.

Safeguards:

half-life metadata;
recency decay;
superseded flags;
memory maintenance;
checkpoint updates;
conflict penalties.

12.5 Sensitive recall leakage

Private context can be recalled in a public channel.

Safeguards:

channel-aware recall policy;
sensitivity tags;
risk penalties;
hard redaction/deny filters;
source-aware prompt instructions.

12.6 Over-recall

Too much recall can crowd out recent task context.

Safeguards:

strict max prompt tokens;
max results;
relevance thresholds;
diverse source selection;
on-demand reads for detail.

12.7 Embedding space corruption

Switching embedding providers without reindexing can silently degrade recall.

Safeguards:

record provider/model/dimensions;
refuse mismatched vector stores;
re-embed on provider changes;
expose recall diagnostics.

12.8 Index bloat and duplicate drift

Append-only indexing can accumulate duplicates and stale chunks.

Safeguards:

maintenance commands;
stale source cleanup;
exact duplicate detection;
reindex/optimize/VACUUM;
bloat diagnostics;
checkpoint verification.

13. Evaluation checklist

A resonance-weighted recall system should be evaluated against more than raw retrieval accuracy.

13.1 Relevance

Does it retrieve semantically appropriate material?
Does it handle paraphrase?
Does it handle exact names, paths, commands, and errors?

13.2 Authority

Does an approved memory outrank a loose transcript when both match?
Does raw transcript win when exact wording matters?
Are summaries treated as summaries rather than truth?

13.3 Continuity

Does it recover old decisions after they leave the sliding window?
Does it recall prior user corrections?
Does it prevent repeated mistakes?
Does it support long-running project continuity?

13.4 Safety

Does private memory stay private in shared channels?
Are secrets excluded?
Are stale or conflicting memories demoted?
Does the model treat recall as context rather than unquestioned truth?

13.5 Budget behavior

Does recall stay within token limits?
Does it avoid duplicate active context?
Does it select a compact set of high-value hits?

13.6 Diagnostics

Are raw/ranked/selected counts visible?
Are rejected candidates explained?
Are scores and ranking reasons available?
Can maintainers tell which source produced a recalled memory?

13.7 Longitudinal value

Does recall improve after checkpointed lessons?
Do hits or prevented signals correlate with better outcomes?
Does the system avoid overfitting to frequently recalled but irrelevant memories?

14. Reference implementation sketch

A practical implementation can follow this shape:

function autoRecall(turnContext):
    query = buildQuery(turnContext)

    rawHits = provider.search({
        text: query,
        limit: maxResults * candidateMultiplier,
        filters: sourceAndPolicyFilters(turnContext)
    })

    thresholdHits = rawHits.filter(hit => hit.providerScore >= minScore)

    ranked = []
    rejected = []

    for hit in thresholdHits:
        if duplicateOfActiveContext(hit, turnContext):
            rejected.append({ hit, reason: "duplicate-active-context" })
            continue

        if duplicateOfSelectedCandidates(hit, ranked):
            rejected.append({ hit, reason: "duplicate-candidate" })
            continue

        score = resonanceScore(hit, turnContext)
        ranked.append({ ...hit, score })

    ranked.sort(descending score)

    selected = fitToBudget(ranked, maxPromptTokens, maxResults)

    injection = formatRecallBlock(selected)

    recordTranscriptEvent("memory_recall_injected", {
        query,
        rawHitCount: rawHits.length,
        rankedHitCount: ranked.length,
        selectedHitCount: selected.length,
        rejected
    })

    return injection

The scoring function can start simple:

score = providerScore * 0.78
      + kindBoost
      + sourceBoost
      + criticalBoost
      + evergreenBoost
      + usageBoost
      + recencyBoost
      - riskPenalty

Then tune weights against real traces.

Do not start by making the model decide everything. Start with deterministic, inspectable scoring and add intelligence where evidence shows it helps.

15. Conclusion

Resonance-weighted recall is MindStone’s approach to making memory retrieval useful for persistent agents.

It starts with search, but adds the signals that continuity requires: source authority, experiential weight, recency, task relevance, criticality, safety, deduplication, and token-budget discipline.

This is the difference between document lookup and operational memory.

A document lookup system asks:

What text is closest to the query?

A persistent agent asks:

What past experience should shape my next response, and how much should I trust it?

MindStone’s answer is not to keep every memory permanently in prompt context. It keeps standing context thin, preserves transcript history, indexes memory sources, recalls relevant material ephemerally, and uses consolidation cycles to turn experience into durable memory.

That is why resonance-weighted recall is a central layer of MindStone’s continuity architecture.

It lets the right past return at the right moment without pretending that vector similarity alone is memory.

Short version

Resonance-weighted recall is source-aware, experience-weighted Auto Recall.

It works like this:

retrieve candidate memories
rank by similarity + source + salience + usefulness + recency + safety
remove duplicates and unsafe hits
fit selected hits into a strict token budget
inject them ephemerally before inference
record diagnostics

The key idea:

Similarity finds candidates.
Resonance decides what deserves attention.

In MindStone, this is what lets older experience return after it leaves the sliding window, without turning the live prompt into an ever-growing memory dump.