The Recall Loop: Making Skills Remember

Memory Is Not Recall

Most operators treat memory as a write-only diary. The agent finishes a task, dumps a summary into the store, and moves on. The store grows. Nothing is ever read back. The next time a similar task comes up, the agent starts from zero — and often repeats a mistake it was already corrected on.

A phenomenal skill closes that gap. It treats the memory store as something to read at the start, not just write at the end. Before the skill does any work, its first step queries memory for the task at hand, ranks what comes back, and injects the most relevant few into the working context. The agent acts with the benefit of everything it has learned — automatically, every run.

This is the recall loop, and it is the single highest-leverage thing you can add to a skill that already works.

The Four Stages

The loop has four moves, and each one matters.

Read at start

The recall step is the first thing the skill does — before it plans, before it touches a file. It calls the memory store with the key terms of the current task:

memory_recall(query: "deploy backend fix host check verification")

The query is built from the task, not hard-coded. A deploy skill recalls deploy lessons; a content skill recalls content lessons. The terms come from what the operator actually asked for, so the recall is scoped to the work in front of the agent.

Rank and filter

The store returns candidates with relevance scores. The loop does not trust the store's order blindly — it applies its own floor. Anything below the threshold is noise, and noise that enters the context is worse than no context at all, because it competes with the signal for the agent's attention.

keep = [m for m in candidates if m.score >= 0.55]

The floor is a deliberate, tunable number. Set it too low and you drown in marginal matches. Set it too high and you discard hard-won lessons. Tune it against real recalls.

Take the top-k

Even above the floor, you do not inject everything. You take the few highest-ranked memories — three is a sensible default. More context is not more signal; past a handful of memories, the marginal one mostly adds tokens and dilutes the rest.

Inject into context

The chosen memories are prepended to the working context as explicit prior knowledge:

"Prior lessons that apply to this task:
 1. Host check first — a localhost-verified deploy proves the shadow stack, not prod.
 2. SSH deploy needs the PATH export or the container tool is not found.
 3. Rebuild AND confirm the service is actually running, not just built."

Now the agent plans the deploy already knowing the three things it has been burned by before.

Ranking Is a Filter, Not a Sort

The most common mistake is treating relevance as a sort — line the candidates up best-to-worst and take the top N regardless of score. That quietly injects garbage whenever the store has few good matches, because the "best" of a bad set is still bad.

Relevance is a filter first, then a sort. The floor decides what is even eligible; the ranking decides the order among the eligible. A memory below the floor never enters the context, even if it is the highest-scoring thing the store returned. When the store has nothing relevant, the right number of injected memories is zero — and that is a correct outcome, not a failure.

Progressive Disclosure: Search Compact, Then Fetch Full

The token cost of recall lives in how you read, not just what you read. The disciplined pattern is two-phase:

1. Search compact. Query the store for short summaries — a sentence or two each. This is cheap and lets you rank a wide candidate set without paying for full bodies.
2. Fetch full for the survivors. Only after ranking and the top-k cut do you pull the complete body of the memories you decided to keep.

Pulling every full body up front and then discarding most of them is the anti-pattern. You paid for context you threw away, and you crowded the model's window doing it. Search compact, rank, then hydrate the few that earned it. This mirrors how a good operator works a knowledge base: skim the index, then read only the entries that matter.

Where the Recall Loop Lives in the Skill

In the skill file, the recall loop is the opening section of the procedure — before the planning step. A deploy skill that already has a host check, an SSH step, and a verification gate gains one new first move: recall the deploy lessons and inject the top few. Everything downstream gets smarter for free, because the plan is now informed by every past correction.

The verification gate at the end of the skill should also confirm the loop ran: did the recall step execute and either inject memories or correctly find none above the floor? A recall loop that silently no-ops because of a malformed query is a loop that has stopped compounding — and you want the gate to catch that.

Build the loop yourself now. Wire a query into a ranked, filtered, top-k injection — the exact mechanism that makes a skill remember.

What's Next

Recall makes a skill act on what it already knows. The next lesson closes the other half of the loop: how a skill grows what it knows. When the operator corrects the agent, that correction has to become a durable, categorized rule — written to memory so this recall loop can surface it next time. That is the self-evolution loop, and it is what turns a static skill into one that gets better every time it is used.