Teaching Alfred to Remember with a Neuroscience-Inspired Memory System for AI Agents

Introduction

My people, its me again. A few months back, I wrote about Alfred, my personal agentic AI assistant. Alfred lives between my inbox, my calendar, my DevOps boards, Teams, and even my robot vacuum. That article walked through how I stitched all those tools together into one agent that actually does things for me instead of just talking about them. If you have not read it, this is a summary: one agent, many tools, enough autonomy to be useful without being reckless.

Near the end of that article, I wrote about something I called the Floodgate Effect which is the moment when adding one more capability suddenly unlocks ten more that were waiting on it. You add calendar access, and now email triage becomes scheduling. You add Teams, and now a "quick question" at 9pm becomes a draft reply before you have finished your coffee. Each new sense Alfred gains does not just add to what he can do; it multiplies it. This article is the direct result of one of those floodgates finally opening. The floodgate of memory.

Now, let us be honest with ourselves. Personal AI agents are everywhere now. Every week there is a new one. Some are wrapped in sleek UIs, some are open-source projects with thousands of stars, some are just clever prompts pretending to be agents. But walk up to any of them and ask, "do you remember when we talked about my mother's birthday?" and watch what happens. Most of them will smile politely and start from zero smh. A few will pull something from storage that is technically related but practically useless. Very few will actually recall the conversation the way a friend would. That gap, that is what this article is about.

The Problem

For all the tools Alfred had access to, he was still, in a very real sense, a stranger to me. A capable stranger, yes, but still a stranger. And the deeper I worked with him, the more I noticed the same three cracks showing up again and again.

He could not remember our conversations

Ask Alfred, "do you remember when we talked about switching electricity providers?" and you would get a blank stare dressed up in polite language. The conversations we had, they lived in the chat window and nowhere else. Once a session ended, whatever we discussed was gone. No recall, no reference, no thread to pull on.

And it got worse with vague questions. "What happened to my money at the beginning of January?" is the kind of question I would ask a human assistant without thinking twice. A human would piece it together from a hundred small signals: the bills that came in, the transfers I mentioned in passing, that one receipt I complained about. Alfred could not do any of that. He could search a single email inbox by keyword, or scan receipts by date, but he could not triangulate across everything the way memory actually works. This was quite important to me tbh

He did not know the basic facts about my life

I would love for alfred to keep some facts about me. Basically for him to have small permanent truths that make someone feel like they actually know you. Every conversation was fresh and started from 0 with 0 important context.

Now, you might ask, does this really matter for an AI assistant? I will tell you why it matters. Without these permanent facts, Alfred could not handle personal tasks with any real context. "Send my sister a birthday message" required me to spell out who my sister is, what her email is, and when her birthday falls, every single time. The value of an assistant collapses the moment you have to brief him from scratch on every task. At that point, you are not being assisted; you are doing the work twice.

He could not learn patterns from experience

This was the subtlest gap, but the most human one. Think about how you yourself learn someone's preferences. You do not sit down and write a list. You order food for your mother five times, and each time she says "no mayonnaise," and by the sixth time you do not need to ask. That piece of information, it has quietly graduated from a passing comment into a permanent fact about her. You did not decide to remember it. Your brain decided for you.

Alfred had no mechanism for this. Every "no mayonnaise" was a fresh instruction. The tenth time was treated exactly like the first. He could execute orders beautifully, but he could not notice what those orders were teaching him about the people in my life.

The sum of the problem

Put these three gaps together and you get an agent that is technically impressive but emotionally flat. He could do the work, but he could not feel like someone who knew me. And that is the thing about a personal assistant: the "personal" part is not decoration. It is the whole point.

Methodology

Before writing a single line of code, I forced myself to stop and think. Because the truth is, my first instinct was wrong. I was looking at the problem reactively, listing the things Alfred could not do and thinking of patches for each one. Patch the recall. Patch the personal facts. Patch the pattern learning. Three patches, three features, ship it.

But patches do not build a memory system. Patches build a mess. What I actually needed was a proper frame, a way of thinking about memory that would tell me which features belonged and which ones were distractions dressed up as good ideas.

Borrowing from how humans actually remember

So I went back to basics and read. Not AI papers, but some cognitive science excepts. And the first useful thing I learned was that human memory is not one thing. It is at least two: episodic memory and semantic memory.

Episodic memory is the record of specific events. "Last Tuesday I had lunch with my sister and she mentioned she was changing jobs." It has a time, a place, a context. It fades, it decays, and most of it eventually disappears.

Semantic memory is different. Semantic memory is the distilled facts you carry with you. "My sister works as a Dr." "My mother does not like sugar." "My girlfriend's birthday is in the middle of the year." These do not have a timestamp attached because they are not events; they are truths. They survive long after the specific conversations that produced them have been forgotten.

The moment I saw this distinction, the three gaps from the previous section snapped into place. Gap one was broken episodic memory. Gap two was missing semantic memory. Gap three was the absence of any mechanism to move facts from episodic into semantic, which in humans is a process called memory consolidation. I was not dealing with three separate features. I was dealing with one missing system.

Discovering that OpenClaw had walked this path already

Now, I am not the first person to think about this for AI agents. I went looking to see who else had wrestled with it. OpenClaw had already built something that went viral so I decided to see how Peter Steinberger handled memory. For those who dont know, OpenClaw is an open source personal AI assistant project. Peter's approach to memory was almost aligned with what I had been reading in cognitive science. They had not just borrowed the vocabulary; they had borrowed the architecture. OpenClaw then became an added inspiration

Here is what I pulled from studying their implementation:

1. Temporal decay. Memories lose weight over time, modelled on Hermann Ebbinghaus's 1885 study of his own forgetting curve. A memory from yesterday outranks a memory from last month, not because it is more relevant but because recency matters to human cognition.
2. Tiered storage between semantic and episodic memory. Two stores, two shapes of data, two different lifespans. Exactly the distinction I had just read about.
3. A memory consolidation pipeline via dreaming. A background process that runs when the agent is idle, reviews the episodic record, and promotes important patterns into semantic memory. Inside the dream, a promotion scoring formula decides what graduates and what does not.
4. Recall tracking. Every time a memory gets retrieved, that fact is logged. Popular memories earn their place; unused ones fade. For engineers think of this as some kind of cache
5. Diversity ranking. When results are returned, near-duplicates get pushed down so the top of the list is actually varied rather than five versions of the same thing.
6. Hybrid search combining full-text search with vector similarity, so both literal keyword matches and semantic matches count.
7. Content hashing for skip-reindex. If a piece of content has not changed, do not waste cycles re-embedding it.
8. Append-only memory writes. You never overwrite memory in place; you add to it. The history is preserved.
9. Chat tools like memory_search that let the agent query its own memory during a conversation, rather than memory being a silent background system.

Picking a north star

Here is where I had to be disciplined. Once you find a toolkit this rich, the temptation is to grab everything and start wiring it up. But tools without a north star become a pile of features, and a pile of features is not a system. I needed one guiding principle that would let me decide, for every new idea, whether it belonged or not.

The principle I settled on was this: neuroscience is the pillar. If a feature had a clear analogue in how humans remember, it was in. If I could not explain it in cognitive terms, it was out or it was waiting for a better justification. This single rule has saved me from at least a dozen clever ideas that would have been technically satisfying and practically useless.

With that north star in place, I took what the OpenClaw project had built, adopted what fit Alfred's shape, and started adapting the rest. Credit where it is due: the OpenClaw work is excellent, and a good portion of what I am about to describe stands on those shoulders. Huge thanks to Peter for this.

Implementation

This is the part where theory meets code. I will walk through the pieces one at a time, in the order that made sense as I was building, and I will show the actual code where the logic lives. Each part maps back to something from the Methodology section, and each one is anchored in the north star: if there is no neuroscience analogue, it does not belong.

Part 1: The cognitive-science mapping

Six mechanisms in Alfred's memory system track real cognitive-science models of how human memory works. Each one earned its place by passing the north star test. Let me walk you through all six.

1. The exponential forgetting curve (temporal decay)

In 1885, Hermann Ebbinghaus, a German psychologist, did something most researchers would never dare to do. He ran his experiments on himself. Day after day, he memorised lists of nonsense syllables and then tested how much he could recall at different intervals. From that long, lonely effort, he produced one of the oldest and most durable findings in psychology: human retention decays exponentially.

The formula looks like this:

R(t) = e^(-t/S)

where R(t) is the probability of recalling an item after time t, and S is a per-item "strength" constant. Some memories have a high S, so they last longer. Others are fragile and fade in hours. But the shape of the curve, it is always exponential.

That is the exact formula Alfred uses to rank memories:

rawScore * exp(-λ * ageDays)    // λ = ln(2) / halfLifeDays

I chose a 30-day half-life, which means a memory's score drops to 50% of its original weight after thirty days, 25% after sixty, 12.5% after ninety, and so on. The key insight, the one that took me a while to fully appreciate, is this: older memories do not vanish. They just become less accessible. They still exist in the store. They still match queries. They just have to work harder to surface above fresher material.

This is exactly how human memory feels. A six-month-old email about the Acme contract is still in your head somewhere. You can recall it if you really try. But an equally-relevant email from yesterday, it will pop into your mind first without any effort. Alfred now behaves the same way.

The choice of thirty days is not arbitrary, and it is not borrowed wholesale from Ebbinghaus either. There is a full calibration argument behind it, including how it compares to Ebbinghaus's actual numbers and how to tune it for different use cases. I will get to that in Part 3 of the article.

2. Semantic vs episodic memory (tiered storage)

In 1972, a cognitive psychologist named Endel Tulving drew a line through the concept of long-term memory that researchers are still building on today. He said human long-term memory is not one system but two:

1. Episodic memory holds specific events tied to time and place. "The meeting last Tuesday where Jane raised the budget concern." It has a when and a where. It is autobiographical.
2. Semantic memory holds timeless facts and concepts. "Jane is on the finance team." No timestamp. No location. Just a stable truth about the world as you know it.

These two systems work together but are structurally different. And that structural difference is what made me realise Alfred did not need one memory store. He needed two.

In the implementation, the dividing line is a single field: datedAt. Every chunk that Alfred ingests either has a date or it does not. If it has a date, it is episodic. It lives in the temporal store, and the forgetting curve from mechanism 1 applies to it. If datedAt is null, it is semantic. It is an evergreen fact, and it does not decay. Ever.

This maps cleanly onto what the OpenClaw project does with evergreen files. In OpenClaw, certain files are marked as evergreen and the decay formula skips them. In Alfred, a null on datedAt does the same work. Same idea, different shape.

A few examples to make it concrete:

• An email from January 14th about a vendor quote. This has a clear timestamp. datedAt gets set. It goes into episodic memory and starts decaying.
• A statement that Jane is allergic to shellfish. There is no meaningful timestamp for this. It is just a fact about Jane. datedAt stays null. It goes into semantic memory and stays at full weight indefinitely.
• A bill receipt from last month. datedAt is set. Episodic. Will decay.
• My girlfriend's birthday. datedAt stays null. Semantic. Never decays.

This single boolean-ish decision, whether or not a chunk has a date, is one of the most load-bearing choices in the entire memory system. It decides what the forgetting curve touches and what it leaves alone. It decides what "fades gracefully" and what "stays forever." And it gives Alfred the same two-tiered structure that Tulving identified in us more than fifty years ago.

3. The consolidation pipeline (hippocampus to cortex)

Here is where the neuroscience gets beautiful. Inside your brain, new experiences are not written directly into long-term storage. They go first to the hippocampus, a small seahorse-shaped structure that acts like a fast, temporary notebook. The hippocampus captures new information quickly, but it does not hold things forever. Its job is to stage experience, not to store it.

The actual long-term storage is the neocortex, the thick outer layer of the brain that holds your facts, your concepts, your permanent knowledge of the world. And the transfer from hippocampus to neocortex, that is the work of sleep. During slow-wave sleep and REM sleep, patterns that have been repeatedly activated in the hippocampus get gradually written into cortical networks. This process is called memory consolidation, and it is why sleep deprivation wrecks learning. You can drill a concept all day, but if you do not sleep, it never quite makes it to permanent storage.

Now, look at what Alfred's memory looks like in the same language:

Every row in that table has a direct neuroscience analogue. The north star doing its job.

Here is how the pieces came together, in the order I built them:

1. First, I built the hippocampus. The dated memory_chunks store captures everything Alfred encounters: emails, receipts, conversations. Fast to write, decays over time, never meant to be the permanent record. This is mechanisms 1 and 2 above doing their work together. Individually, dated storage and temporal decay do not mean much. Combined, they are a hippocampus.
2. Second, I added the sleep cycle. A scheduled job called DreamPromotion runs once every 24 hours. It looks at the hippocampal traces, scores them, and promotes the hot ones into neocortical storage. The scoring formula takes into account how often a chunk was recalled, how diverse the queries that surfaced it were, and how the chunk has aged. Not every trace makes it. Most do not. But the ones that do, they become evergreen.
3. Third, I made the whole thing queryable from chat. Alfred gained a memory_search tool and a memory_remember tool, so he can consult his own memory mid-conversation and write to it explicitly when I tell him to. Without this, the memory system would have been a silent background process. With it, memory became a first-class part of the conversation.

A note on the terminology. The OpenClaw project calls their scheduled consolidation job "dreaming," and I kept that name when I adapted the idea for Alfred. It is not a cute branding choice. It is load-bearing. The word "dreaming" communicates, in one syllable, what this process is and why it exists. It signals that the agent is doing something humans also do, and that the purpose is consolidation rather than active work. Every time I see DreamPromotion in the codebase, I am reminded of what I am actually modelling. That is the kind of name that pays for itself.

4. Spreading activation and retrieval-induced strengthening

John Anderson, a cognitive scientist at Carnegie Mellon, built a framework called ACT-R (Adaptive Control of Thought-Rational) that models how the mind retrieves memories. One of the central claims of ACT-R is this: retrieval is not passive lookup. Every time you successfully recall a memory, the trace itself gets strengthened. It does not just sit there being remembered; it becomes easier to remember the next time.

This is the mechanism behind what educators call the testing effect. It is why flashcards work. It is why rereading a textbook, by contrast, barely moves the needle. Passive rereading leaves the traces untouched. Active recall drives them deeper into long-term storage. The memories you use grow stronger; the ones you ignore fade faster.

Alfred's recall tracking is exactly this idea, wearing a software hat. Every time memory_search returns a chunk that actually gets used, the event is logged to a table called memory_recall_log with a normalised query hash, the score that surfaced the chunk, and a timestamp. Over time, three signals accumulate:

• Frequency, how often the chunk has been recalled
• Recency, how recently it was last recalled
• Diversity, how varied the queries are that keep pulling it up

These three feed into a promotion score, and chunks that cross the threshold get graduated into a location that is cheaper to reach. The chunks that never get pulled up, they decay and eventually stop appearing in results altogether. The memory rewires itself around what actually gets used. That is not a metaphor. That is what the code does.

5. Pattern separation (MMR diversity ranking)

There is a specific structure in the hippocampus called the dentate gyrus, and its job in the brain is almost architecturally neat. It performs what neuroscientists call pattern separation: it takes similar experiences and makes them distinguishable so they do not smear together in memory. Without pattern separation, yesterday's commute and today's commute would blur into a single vague memory of "commuting." With it, you can recall them as distinct episodes even though they are 95% the same.

Alfred does the computational equivalent using a technique called Maximal Marginal Relevance, or MMR. The logic is simple. If three different emails all mention the Q3 marketing budget, stuffing all three into the agent's context window tells him nothing new. He already has the Q3 marketing budget point. What he needs is breadth. MMR handles this by picking the most relevant result first, then picking the next result that is both relevant and different from what has already been selected:

score = λ * relevance - (1 - λ) * maxSimilarityToSelected

The λ parameter decides how aggressively to push for diversity. A higher λ favours raw relevance. A lower one favours variety. What you get is pattern separation as an optimisation function. The top results end up being distinct from one another rather than five near-duplicates of the same point.

6. Mental time travel (temporal retrieval)

In 1997, Thomas Suddendorf and Michael Corballis introduced a term that has stuck in cognitive psychology ever since: mental time travel. Refined further in their 2007 work, the concept describes the uniquely human ability to mentally project yourself backward or forward in time. Backward, you re-experience past episodes. Forward, you pre-experience future ones. Either way, you are navigating deliberately to a specific temporal location in your mind.

This is what lets you answer a question like "what happened at the party last Saturday?" You do not sit there hoping the memory is fresh enough to float to the top. You go to last Saturday. You project yourself to that point in time and then recall from there.

Now, this is different from the forgetting curve, and the difference matters. Ebbinghaus-style decay governs accessibility, how easily a trace comes to mind when you are not even looking for it. Mental time travel governs deliberate retrieval, the ability to restrict your search to a specific window of time regardless of how activated the traces are. You need both. Without decay, everything would feel equally loud and you could never find the important things. Without temporal retrieval, you could not quiet the present long enough to hear the past.

The gap before this fix

After implementing mechanisms 1 through 5, Alfred had the forgetting curve but not mental time travel. He could tell you what was top-of-mind, meaning the fresh and frequently-recalled stuff, but he could not deliberately navigate to a specific time window.

A question like "what was happening with Acme in January?" would fail in practice. Why? Because January chunks had been decaying for three or more months by the time I asked. They ranked near the bottom no matter how relevant they were. The decay mechanism was doing double duty: modelling both "what is fresh" and "when did it happen." Those are two different questions, and one formula cannot answer both.

The fix

I added two optional date fields to MemorySearchOptions, after and before, both ISO-8601 strings. The FTS5 query gained a temporal boundary clause:

AND (c.dated_at IS NULL OR c.dated_at >= :after)
AND (c.dated_at IS NULL OR c.dated_at <= :before)

Notice something important in that SQL. Evergreen chunks, the ones where dated_at IS NULL, always pass through the filter. And that is correct. If the user asks "what do I know about Acme from January?" and there is an evergreen fact that says "Acme's account manager is Jane," that fact is just as true in January as it is now. It is a timeless truth, and a time window should not exclude it.

How decay and windowing interact

Within a time window, decay still applies. A chunk from January 15th still ranks above one from January 2nd, all else equal. The window restricts the candidate set; decay ranks within it. Two mechanisms, each doing its own job, working together.

This matches how mental time travel actually works in humans. You project to "the party last Saturday," which is the window. Then the most salient moments from that episode surface first, which is activation and recency within the window. The two mechanisms are orthogonal. One filters. The other ranks.

How the agent routes

The memory_search chat tool now has optional after and before fields. The intent-extraction LLM picks between Alfred's structured tools and memory_search based on the shape of the question:

1. Specific source, with time. Use a structured tool: search_emails, bill_receipts, finance_query. These have their own date-range parameters and return richer, source-specific results.
2. Cross-source, with time. Use memory_search with after and before. A question like "what was going on in January?" spans emails, receipts, and conversations. The temporal window scopes the search; decay and MMR rank within it.
3. Cross-source, no time. Use memory_search without date filters. Standard recall: decay naturally favours recent material, and the user has not asked to override that default.

That simple three-way split captures most of how a human would mentally sort the question before even beginning to remember. Is this about one specific place? Then go there. Is this about a particular time across everything? Then project there. Is this about everything in general? Then let the most activated memories float up on their own.

Part 2: How the pieces actually work

Part 1 told you why each mechanism exists. This part tells you what the machinery actually is, so you can reason about its behaviour and its limits. If the first part was cognitive science, this one is the wiring diagram.

FTS: how the index finds matches

The problem full-text search solves is simple. How do you find documents by what is inside them, fast?

Without FTS, searching for an email mentioning "contract acme" means scanning every row with body LIKE '%contract%' AND body LIKE '%acme%'. On fifty thousand rows, that is fifty thousand full-text comparisons per query. Slow. It also cannot rank by relevance, cannot handle partial matches well, and cannot tell you which result is "most about" your query.

FTS builds what is called an inverted index, which is a map from every word to every row that contains it. Think of the index at the back of a textbook:

"acme"     → rows 42, 108, 391, 2504
"budget"   → rows 12, 42, 205, 1337, ...
"contract" → rows 42, 73, 391, 2504, ...

When you query "contract" AND "acme", the engine intersects the two lists in milliseconds and gives you back rows 42, 391, and 2504. No row scanning. No LIKE wildcards. No sweating.

Alfred uses FTS5, which is version 5 of SQLite's built-in full-text search module. It ships inside better-sqlite3, so no new dependencies were added. What I got out of the box:

1. MATCH syntax, for example WHERE memory_chunks_fts MATCH '"contract" AND "acme"'.
2. BM25 ranking, a standard relevance formula from the same family Google used before they moved to machine learning ranking. It scores by term frequency, inverse document frequency, and document length.
3. Sublinear scaling. Search time grows much more slowly than the corpus. One hundred thousand chunks still return in a few milliseconds.
4. A pluggable tokeniser. I use unicode61, which handles accents, case, and punctuation correctly without any extra configuration.

BM25: how FTS ranks

BM25 returns a number where lower is better. A rank of 0 means a near-perfect match; higher numbers mean progressively worse matches. That is backwards from how the rest of Alfred's pipeline thinks about scores, so the memory adapter inverts it into a 0 to 1 relevance score:

rawScore = 1 / (1 + max(0, bm25_rank))
// bm25 ≈ 0  → rawScore ≈ 1.0
// bm25 = 1  → rawScore = 0.5
// bm25 = 9  → rawScore = 0.1

This is a conventional way to turn BM25 into a bounded score, and it keeps the arithmetic stable when you later multiply it by decay coefficients, which also live in [0, 1]. Everything in the ranking pipeline now speaks the same language.

MMR: the algorithm, up close

I already covered what MMR is conceptually in Part 1 and gave the formula. Here I want to show you what actually happens when it runs.

The algorithm is greedy, meaning it picks one result at a time rather than trying to optimise the whole list at once:

1. Pick the highest-scoring candidate first. Nothing has been selected yet, so there is nothing to be similar to.
2. For each remaining candidate, compute its MMR score against the set of items already picked.
3. Pick the winner. Repeat until you have N results.

For the similarity measure, I used Jaccard similarity on lowercased word tokens:

jaccard(A, B) = |A ∩ B| / |A ∪ B|

Two identical texts score 1.0. Totally disjoint texts score 0.0. It is cheap to compute, needs no embeddings, and is good enough for catching near-duplicates in short text.

Now let me show you the algorithm working on a real-looking example. Suppose BM25 returns five candidates for the query "marketing budget", all with relevance around 0.9:

A: "Please approve the Q3 marketing budget"            0.95
B: "Please approve the Q3 marketing budget for sure"   0.94   (near-dup of A)
C: "Please approve the Q3 marketing budget (revised)"  0.93   (near-dup of A)
D: "Marketing budget alert: Q3 dining over limit"      0.70
E: "Budget meeting notes: marketing, eng, ops"         0.65

Without MMR, your top three results are A, B, C. All three are essentially the same email. Results two and three teach the agent nothing he did not already get from result one.

Now watch what happens with MMR at λ = 0.7:

• A is picked first. It is the highest raw score.
• For B: relevance is 0.94, but Jaccard similarity to A is around 0.9. MMR score = 0.7 · 0.94 − 0.3 · 0.9 = 0.39.
• For D: relevance is 0.70, but Jaccard similarity to A is around 0.3. MMR score = 0.7 · 0.70 − 0.3 · 0.3 = 0.40.
• D wins second place, even though its raw relevance was much lower. The same logic picks E third.

The final top three is A, D, E. Three genuinely distinct perspectives on the marketing budget instead of three copies of the same thread. That is pattern separation, paying for itself every single query.

Temporal decay in concrete numbers

I showed the decay formula in Part 1. Here is what it actually produces, which is the part that makes the behaviour click:

Two implementation details are worth naming:

1. Null-dated chunks bypass decay entirely. This is the evergreen tier from Part 1, enforced in code rather than hoped for.
2. Future-dated chunks are treated as "now." This is an edge case, but without it, a chunk dated tomorrow would get an amplified score above rawScore, which is nonsense. Clamping the age to zero prevents the math from misbehaving.

Content hashing: why the indexer is cheap to call

Every indexer in Alfred, whether it is IndexEmailMemory, IndexBillReceiptMemory, IndexConversationMemory, or AddEvergreenFact, follows the same pattern:

const contentHash = sha256(text);
const existing = await port.getSourceHash(sourceType, sourceId);
if (existing === contentHash) return;  // skip the re-index
await port.upsertSource({ sourceType, sourceId, contentHash, chunks });

The memory_sources table stores the last known hash alongside each source. On repeat calls, the hash lookup short-circuits the expensive work of chunking and rewriting the FTS index. If the content has not changed, nothing happens.

This is why it is safe to call IndexConversationMemory on every single chat message insert. Technically, a new message's content never matches an existing hash, so the skip never fires on the insert itself. But on retries, reprocessing, or replaying an event stream, the hash lookup makes the call a no-op. Idempotency for free.

Chunking: how long documents get split

The chunker in chunkEmail is intentionally simple:

1. Concatenate subject + "\n\n" + body.
2. Strip HTML tags and decode common entities. Gmail bodies are often HTML, and the tags carry no signal worth indexing.
3. Normalise CRLF line endings and collapse runs of three or more newlines down to two.
4. Split on blank lines into paragraphs.
5. If a paragraph exceeds MAX_CHUNK_CHARS (set to 1200), hard-split at that boundary.
6. Drop anything below MIN_CHUNK_CHARS (set to 40). Too short to contribute useful signal.

Receipts, chat conversations, and evergreen facts skip chunking altogether. They format the whole record into a single text block and index that as one chunk. This asymmetry is deliberate. Emails have multi-paragraph bodies where different paragraphs carry different meaning, so per-paragraph addressing is worth the effort. Receipts and conversations are coherent units where splitting would fragment the signal instead of sharpening it.

Recall tracking: what the system actually observes

The concept of recall tracking was covered in Part 1. Here are the shape and the subtle details.

Every successful SearchMemory.run(query) that returns at least one result emits a RecallEvent per returned chunk into the memory_recall_log table:

interface RecallEvent {
  chunkId: string;
  queryHash: string;   // sha256 of lowercased + normalised query
  score: number;       // the finalScore at recall time
  recalledAt: string;  // ISO 8601
}

The query is normalised before hashing. Trim whitespace, collapse internal runs of whitespace, lowercase the whole thing. This means "Acme contract", " acme contract ", and "ACME CONTRACT" all produce the same hash. This matters. Without normalisation, those three cosmetic variants would count as three distinct queries, and the diversity signal would be garbage. With normalisation, we can honestly say "this chunk was surfaced by N genuinely different queries," which is the thing we actually want to measure.

The log is pruned to the scoring window (thirty days by default) at the end of each dreaming run, so it stays bounded no matter how heavy the recall traffic gets.

Promotion scoring: the dreaming formula

When the dreaming job runs, it takes the recall log and aggregates it per chunk into a small summary:

ChunkRecallStats {
  recallCount,
  uniqueQueryCount,
  maxScore,
  lastRecalledAt
}

Each candidate then gets scored with a four-component weighted formula:

frequency = log1p(recallCount)      / log1p(NORM_RECALLS)   // 0.30 weight
relevance = clamp01(maxScore)                               // 0.35 weight
diversity = log1p(uniqueQueryCount) / log1p(NORM_QUERIES)   // 0.20 weight
recency   = exp(-ln2/14 · daysSinceLastRecall)              // 0.15 weight

promotionScore = weighted sum, clamped to [0, 1]

The weights sum to 1.0 by design. The log1p scaling on frequency and diversity prevents a handful of viral queries from dominating the score. A chunk recalled one hundred times does not get a hundred times the credit of a chunk recalled once; it gets roughly twice as much, which feels closer to how human attention actually works.

This is a deliberately simplified version of the six-component scoring OpenClaw uses. I dropped the "consolidation phase signal" and "conceptual tag" terms because Alfred does not have the inputs to compute them honestly, and I redistributed their weights across the remaining four. A simpler formula you fully understand is better than a richer one you half-trust.

The thresholds for promotion are conservative by design:

score ≥ 0.60 AND recallCount ≥ 3 AND uniqueQueryCount ≥ 2

In plain English: the chunk must be sufficiently scored, recalled at least three times, and hit by at least two genuinely different queries. A single viral query cannot force a promotion. A single user cannot accidentally promote a junk memory by asking the same question over and over. Both volume and variety are required.

All six constants in the scoring formula live in a single place. Tuning any of them is a single-line change.

Part 3: Calibrating the decay (why 30 days?)

Somebody who has heard of Ebbinghaus is going to read Parts 1 and 2 and immediately ask: "Hold on. Is not the famous forgetting curve a one-hour half-life? Why is Alfred sitting at thirty days?" The short answer is that the comparison is misleading. The longer answer is what this section is for, and I will keep it tight.

Ebbinghaus measured something very specific. He memorised nonsense syllables, with no rehearsal, no meaning, and no context. Under those brutal conditions, retention did halve in about an hour. But the formula is R(t) = e^(-t/S), and the S is a stability constant that depends entirely on what kind of memory you are modelling. Meaningful, contextually-encoded information you engage with periodically has a vastly higher S than random syllables in a lab. The shape stays exponential; only the constant changes. Quoting "one hour" as if it were a universal forgetting rate is the same error as quoting "100 °C" as if it were a universal boiling point. True under one set of conditions, badly misleading otherwise.

The other thing to clear up is what "decay" even means here. Ebbinghaus measured retention: can you reproduce the syllable at all? Alfred measures ranking: where does this chunk sit in a search result list? A six-month-old chunk in Alfred is at a score of about 0.016, but it is still fully searchable, fully readable, fully present. It just will not outrank a one-day-old chunk on the same query. This is much closer to John Anderson's ACT-R concept of memory activation (how easily does it come to mind?) than to Ebbinghaus's retention (is it there at all?). In plain terms: Alfred does not forget. It buries. If a user explicitly searches for "Acme contract from October," the FTS5 index will find it. Decay only kicks in when ranking needs to choose between several matches.

Given all of that, why thirty days specifically? Three reasons:

1. Monthly bill cycles. Receipts you paid this month are most relevant; last month's are less so; older ones are usually closed business. Alfred handles my bills, and the domain has a monthly heartbeat.
2. Typical lookback in conversation. "What did Jane say last week?" or "last month?" are common. "What did Jane say last quarter?" is rare.
3. The promotion path does the rest. Anything important enough to survive past three months gets picked up by the dreaming job and promoted to evergreen, where decay does not apply at all. So the half-life only needs to behave well on the window before promotion has had a chance to do its work.

It is a design choice, not a discovered constant. And because it is a design choice, it is tunable:

The constant lives in temporal-decay.ts as HALF_LIFE_DAYS = 30. If retrieval ever surfaces too much old material, I lower it. If useful older content keeps getting buried, I raise it. It is a knob, not a law.

Part 4: Memory versus RAG

Now, before we go any further, I want to head off a misconception that a certain kind of reader will already be forming. "This is just RAG," they are thinking. "Chunking, indexing, ranked retrieval, feeding context into an LLM. You have built RAG and you have called it memory."

I need to push back on that, because it is half right and half importantly wrong.

RAG, or Retrieval-Augmented Generation, is a pattern for feeding context into an LLM at inference time. The usual shape is this: embed the question, run a vector search over a document store, stuff the top chunks into the prompt, and let the LLM generate a grounded answer. RAG is a stateless lookup plus generation pipeline. It is excellent at what it does, and Alfred's memory system genuinely does borrow RAG's retrieval step. Chunk, index, search, return ranked results. That spine is the same.

But look at what diverges from there:

Read that table carefully, because the pattern in it is the whole point. The first five rows describe a retrieval system. The last four describe something else entirely: a system that changes over time based on how it gets used. That is what separates memory from lookup.

A RAG pipeline does not know or care whether you have searched for the same thing a hundred times. Alfred does, and the dreaming job rewards the chunks that keep getting pulled up. A RAG pipeline treats a document from three years ago exactly the same as one from this morning. Alfred does not, because recency is a signal about what is likely to matter now. A RAG pipeline serves the retrieval and then forgets you were ever there. Alfred writes your recall back into its own state and uses it to shape tomorrow's results.

Today, the retrieval side of Alfred is FTS5 rather than vectors, but that is a tactical choice, not a philosophical one. A later phase will add embeddings on top, making this a hybrid vector plus full-text pipeline. None of the contracts above will need to change when that happens. The decay, the consolidation, the MMR, the recall log, the evergreen tier: all of them sit above the retrieval layer and are agnostic to how the candidate set gets produced.

So yes, Alfred's memory uses RAG-grade retrieval. But the three things that push it beyond RAG are time, learning, and source mixing. Those are what make it worth calling memory instead of search. A system that finds things is retrieval. A system that finds things, notices what you keep asking for, promotes the persistent patterns, and fades the rest, that is something else.

Gaps, Discoveries, and Adaptations

When you adopt a design wholesale from somewhere else, the easy thing is to copy it and move on. The honest thing is to keep looking at it after you have copied it, because the shape that works for the original is almost never the exact shape that works for you. Every time I looked at what I had ported from OpenClaw, I found one more thing that was either incomplete for my use case or missing entirely. What follows is the short list of those discoveries and what I did with each one.

The forgetting curve alone is not enough

This is the discovery I covered in depth in Part 1, so I will not re-litigate the fix. But the shape of the gap is worth naming clearly here, because it is the most important discovery in the whole project.

Alfred had the forgetting curve. What Alfred did not have, and what OpenClaw also does not have, was mental time travel. The system could tell me what was top-of-mind, but it could not deliberately navigate to a specific episode. A question like "what was going on at the start of the year?" failed not because the information was gone but because the ranking formula had buried it under three months of decay.

This was not a small oversight. It was a structural blind spot in OpenClaw's design, and once I saw it, I could not unsee it. Decay answers "what is fresh?" Temporal windowing answers "what happened then?" Both are independently necessary, and OpenClaw had solved only one of them. Adding after and before boundaries to memory_search, with evergreen chunks passing through untouched, is what closed the gap.

OpenClaw assumes one source type. Alfred has four.

OpenClaw indexes markdown files. That is the entirety of its ingestion surface. If it is not markdown, it does not go in.

Alfred's world is messier. My inbox is HTML. My bill receipts are structured JSON extracted from PDFs. My chat conversations are multi-turn transcripts. My evergreen facts are short plain-text statements. Four fundamentally different data shapes, all of which need to coexist in a single index and be ranked against each other in a single result set.

This forced two adaptations that OpenClaw simply did not need to make.

The first was an HTML stripper in the chunker. Gmail bodies arrive wrapped in the usual soup of <div>, <style>, and <script> tags, plus the full menagerie of HTML entities. Indexing that raw would pollute the FTS index with markup tokens that carry zero semantic signal. So before chunking, the email path strips tags, decodes entities, and normalises whitespace. OpenClaw has no such code because OpenClaw never sees HTML.

The second was per-source formatters. Emails go through chunkEmail, which splits on paragraphs and hard-breaks long paragraphs. Bill receipts go through formatBillReceiptText, which produces a single formatted block from the structured fields. Conversations go through formatConversationText, which flattens the turn structure into one indexable unit. All four sources feed the same index, but each has its own strategy for turning raw data into text that is worth indexing. OpenClaw has one formatter because OpenClaw has one source type.

This is a case where adapting a system revealed a whole category of work the original did not have to do. Not a flaw in OpenClaw; just a difference in domain.

OpenClaw's evergreen memory is automatic only. I needed it to be teachable.

In OpenClaw, the evergreen tier is populated by one thing and one thing only: the dreaming job. The system learns what to remember permanently by watching what gets recalled over time and promoting the winners. That is a beautiful mechanism, and I kept it entirely for Alfred.

But it is not enough on its own, and the missing piece is something a user of the system would notice within their first week. Let me walk through it as three separate questions I asked myself:

"What if I want Alfred to remember something specific, right now?" Say I want him to know that my girlfriend is allergic to shellfish. That is a fact. It is not going to emerge from recall patterns over weeks of dreaming; it is just something I want him to know starting today. In OpenClaw, the only way to do this is to manually edit MEMORY.md, which is fine for a developer but is not a user-facing interface. So I added a dedicated path for it: a memory_remember chat tool, a /remember CLI shortcut, and an AddEvergreenFact use case behind both. "Remember that my girlfriend is allergic to shellfish" is all it takes, and the fact lands in the evergreen tier immediately.

"What if an evergreen fact changes or was wrong?" Facts go stale. People move jobs, relationships change, preferences evolve. OpenClaw has no mechanism for removing an individual promoted fact. Once something is in MEMORY.md, it stays there unless you manually edit the file. That is not acceptable for a system that is supposed to know me. So I added memory_forget as a chat tool and RemoveEvergreenFact as the underlying operation. "Forget that my sister lives in London; she moved back to Accra last month" is one message, and the stale fact is gone.

"What if I just want to see what Alfred knows about me?" This one is partly practical and partly about trust. A memory system that silently accumulates facts about you is a memory system you have to take on faith. I did not want that. I wanted to be able to ask Alfred at any moment, "what do you remember about me?" and get a complete, structured answer back. Not a vague summary. The actual list, with IDs, with the method by which each fact was learned (user-taught or dream-promoted), and with the date it was captured. OpenClaw does not expose its memory state this way. The recall tracking is internal infrastructure, not a user surface. So I added memory_list_facts and ListEvergreenFacts to close the loop.

Together, these three tools turn evergreen memory from a one-way funnel into a two-way conversation. Alfred can still learn automatically through dreaming. But now I can also teach him directly, correct him when he is wrong, and audit him whenever I feel like it. And all of this sits on top of the same underlying storage as everything else. An evergreen fact is, in the end, just a chunk in memory_chunks with datedAt = null. No new table, no new schema, no special path through the search pipeline. Just a null where a date would normally go.

A quick word on what did not need adapting

It is worth saying, for balance, that most of what I ported from OpenClaw worked in Alfred without changes. The temporal decay formula is essentially identical. MMR is the same minus some tokenisation tweaks I did not need. The BM25-to-score inversion uses the exact same formula. Append-only writes, content hashing for skip-reindex, the memory_search tool itself: all straight adaptations.

The gaps I have described in this section are the exceptions, not the rule. They mattered because they were structural, not because they were numerous. And each one taught me something slightly different about what makes a memory system feel like it actually belongs to the person using it.

Closing

When I started this work, the problem felt small. Alfred cannot remember things. Fix that. Ship it.

What I found instead was that "memory" is not a feature you bolt onto an agent. It is the thing that decides whether the agent feels like a stranger or like someone who knows you. Every gap I described in the Problem section, they were symptoms of the same underlying absence. Alfred could do the work, but he could not build a picture of me while doing it. He had tools but no continuity.

Fixing that took the long route. A trip through cognitive science, an honest study of what OpenClaw had already solved, a north star borrowed from neuroscience, and then a careful adaptation that respected both where OpenClaw got it right and where its shape did not fit mine. The result is a system where six mechanisms work together to do what one formula never could.

Let me tell you what it actually feels like to use now.

One question, many sources. Before, asking "what was that electricity thing?" meant knowing to check the inbox separately from receipts, separately from chat history. Three different mental models, three different query patterns. Now, one call to memory_search("electricity") returns the TNB email thread, the corresponding bill receipt, and the conversation where we discussed power costs. All ranked together, all in one result set. I do not need to know where the information lives. Alfred does.

Alfred learns what matters to me without being told. Every recall logs quietly. Every night the dreaming job reads the log and promotes the chunks that have earned their place. After a few weeks of normal use, Alfred has accumulated a personalised fact base that he built from observation, not instruction. "TNB bills arrive around the 7th of the month." "Jane's replies usually land within 24 hours." "When I say 'the contract,' I mean Acme." I never had to say "remember this." He noticed.

I can teach him things directly when I want to. "Remember that I am allergic to shellfish" is one message, and the fact lands in evergreen memory. It will surface on the next dinner invitation, the next restaurant receipt, the next meal-related email. And "what do you remember about me?" returns a full list so I stay in control of what he knows and can correct anything that has drifted.

Time-bounded recall across everything. "What was happening with Acme in January?" used to have no good answer. Now, memory_search("Acme", after: "2026-01-01", before: "2026-02-01") returns January's emails, receipts, conversations, and any evergreen facts about Acme, all in one ranked result. Alfred can navigate my timeline, not just my recent memory.

Old information fades gracefully instead of crowding the present. The search used to order results by raw timestamp with no relevance weighting, no decay, no diversity. A vaguely-matching email from today beat a perfect match from last week. Five emails in the same thread all showed up. Now, BM25 ranks by relevance, temporal decay applies a gentle 30-day half-life, and MMR ensures the top results are actually distinct. The ranking feels the way a human would naturally remember: recent and relevant floats up, old noise sinks, and the same thing does not appear five times in a row.

What I am taking away from this

A few things have stuck with me from building this out.

The first is that the right frame is worth more than the right code. When I started, I had a list of features and no theory. I could have built every one of those features, and what I would have ended up with is a drawer full of disconnected tools that did not add up to anything. The episodic-versus-semantic distinction, the hippocampus-to-cortex consolidation story, the ACT-R view of retrieval as strengthening: none of these wrote a single line of TypeScript for me, but every one of them told me which lines were worth writing.

The second is that adapting someone else's work is its own discipline. I did not build most of what is in Alfred's memory from scratch. The OpenClaw project had already done the hard thinking on decay curves, MMR, dreaming cycles, and recall tracking. What I did was put all of that into a new body, one with emails and receipts and conversations and a different shape of user, and in doing so I discovered where the original had its own blind spots. Temporal windowing, user-taught facts, per-source formatters: none of these would have surfaced if I had just built from zero. They only appeared because I adapted. Credit where it is due is not just a polite gesture; it is an acknowledgement that this kind of work is built on other people's shoulders and gets better when we say so openly.

The third is that a good agent is not a clever one; it is a contextual one. I used to think the difference between a useful agent and a toy was how sophisticated the reasoning was. I no longer believe that. The difference is context. An agent who knows my sister's email, my girlfriend's allergies, my monthly bill rhythm, and the conversations we have had is infinitely more useful than an agent with twice the IQ and none of that context. The reasoning is the easy part, honestly. The knowing is the hard part. Memory is how an agent starts to know.

What is next

Alfred is not finished. A few things are already on the path for the next phase.

Embeddings are the biggest one. Today the retrieval side is FTS5, which is excellent at keyword matching but has no concept of semantic similarity beyond what the tokens literally share. Adding a vector layer on top, with a hybrid ranker that blends BM25 and cosine similarity, will close a class of queries that currently fail silently. "What did we discuss about budgets?" should also surface a chunk that says "we looked at the Q3 spending plan" even though neither "budget" nor "discuss" appears in the text. Hybrid search makes that possible.

Beyond embeddings, the things I want to try next all fall into the same family: giving Alfred richer ways to notice what matters. Better promotion signals. Evergreen facts with structured relationships rather than just free text. Maybe a second dreaming phase that looks for contradictions between evergreen facts and flags them for review. All of these are in the direction of the same north star. If humans do something like it in their own memory, it is worth trying in Alfred. If they do not, it is probably a distraction.

One last thing

If you have made it this far, I owe you a real thank you. This article was longer than I meant it to be, but every section earned its place in my head and I hope it earned its place in yours. If you want to see the previous article in the Alfred series, it is here. If you want to go look at OpenClaw, the source of so much of what made this possible, it is here.

And if you take one thing from all of this, let it be this: the "personal" in personal AI assistant is not a label. It is the whole point. An agent that does not know you cannot truly help you. An agent that does, quietly becomes something else. Something closer to the help you actually wanted in the first place.

That is what I am trying to build with Alfred. And for the first time, I think he is starting to feel like it.