Show HN: AI memory with biological decay (52% recall) (github.com)

98 points by SachitRafa ↗ HN
Most RAG setups fail because they treat memory like a static filing cabinet. When every transient bug fix or abandoned rule is stored forever, the context window eventually chokes on noise, spiking token costs and degrading the agent's reasoning.

This implementation experiments with a biological approach by using the Ebbinghaus forgetting curve to manage context as a living substrate. Memories are assigned a "strength" score where each recall reinforces the data and flattens its decay curve (spaced repetition), while unused data eventually hits a threshold and is pruned.

To solve the "logical neighbor" problem where semantic search misses relevant but non-similar nodes, a graph layer is layered over the vector store. Benchmarked against the LoCoMo dataset, this reached 52% Recall@5, nearly double the accuracy of stateless vector stores, while cutting token waste by roughly 84%.

Built as a local first MCP server using DuckDB, the hypothesis is that for agents handling long-running projects, "what to forget" is just as critical as "what to remember." I'd be interested to hear if others are exploring non-linear decay or similar biological constraints for context management.

GitHub: https://github.com/sachitrafa/cognitive-ai-memory

35 comments

[ 5.8 ms ] story [ 78.8 ms ] thread
you just make Alzheimer a feature lol , but seriously this is very interesting
I am sorry but the whole "biological memory" thing seems like marketing fluff on basic cache mechanisms.

You said it cuts token usage by 84% but isn't that typical for any typical chunked RAG system?

And why did you specifically chose to test against the LoMoCo dataset when there's a lot of issues with it and it being very easy to cheat?

Hi Builder here, biological is here doing the rhetorical work. The actual mechanism here is exponential decay with category specific half lives, recall based reinforcement and pruning context which falls below threshold.

The main difference between a cache and this framework is that it prunes data not only based on recency but also based on importance and category failures fades fast, strategies persists longer, facts stays longer and assumptions fades faster so on.

The 84% is against storing everything forever. The parameter where it beats RAG is handling contradictions and maintaining the memory size near constant with active pruning of data.

Have also benchmarked it against LongMemEval-S dataset the results are in the repo

I haven’t had much like with memory implementations. I tried a few.

What I do now is preserve all my claude code conversations and set the context from there.

This allows me to curate memory and it’s been the best way so far.

on the other "biological memory" post in so many weeks, I pointed out that the decay rate shouldn't be based on a real clock but a lifetime of it's use within the coding session. Elsewise your memory fades even when there's no process change (eg, coder goes on vacation). I'm not going to check whether thats true here, but it seems like a naive first assumption thats failed conceptualization.

The other comment is that spatial memory is probably a better trigger for memory, so if you're not tracking where the coding session starts, the folders it's visits, etc, then you're not really providing a good associative footpath for the assistant to retrieve whats important for any given project.

Wall clock decay punishing vacation is a issue. The current state of a clock decay is for simplicity but I do see how a session based decay might be helpful.

For failures and strategies it still might work as env drift on calendar anyhow (new version upgrade etc.). But for user preferences it does not.

I agree spatial memory tracking folder visits and session context as retrieval signal would be stronger I agree to that will try to incorporate !

(comment deleted)
I know everybody seems to want the agent to remember every conversation they've ever had with it, but I just don't see the value in that. In fact, it seems to hurt productivity to have the agent second guessing me based on something I said yesterday. Every time I've used any memory system, the agent gets distracted from the current tasks based on previous conversations and branches of development...often comingling unrelated projects (I work on code for work, open source projects, a bunch of unrelated side projects, etc.) and trying to satisfy requirements that don't make sense.

I've stopped trying to achieve general "memory". I just ask the agent to thoroughly, but concisely, document each project. If it writes developer documentation and a development plan/roadmap, as though a person was going to have to get up to speed and start working on the project, it provides all the information the agent needs tomorrow or next week to pick up where we left off.

The agent is not my friend. I don't need it to remember my birthday or the nasty thing I said about React last week. I need it to document what anyone, agent or human, would need to know to get productive in a particular repo, with no previous knowledge of the project.

Good, concise, developer and user documentation and a plan with checklists solves every problem people seem to think "memory" will solve: It tells the agent what tech stack to use (we hashed it out in planning), it tells it what commands it needs to run and test the app, it covers the static analysis tools in use (which formalizes code style, etc. in a way a vague comment I made a month ago cannot), and it is cheap. Markdown files are the native tongue of agents. No MCP, no skills, no API needed. Just read the file. It works for any agent, any model, and any human just getting started with the project.

Basically, I think memory makes agents dumber and less useful. I want it to focus on the task at hand.

Comingling unrelated projects is a fair argument for this. But the goal is here not to cater to specific project patterns but general standards you want to use across project.

Using MD files for this is fine till a point. If you keep on adding information in your md file it will bloat up and will have a huge amount of data to go through it might also have some noise which will be picked each and every time that md file is read into the memory.

Decay of unwanted data is very important factor to build up a good context for our agents. Maintaining a md file is also an overhead as either you will ask the agent to auto update it or have to do it manually.

The file will also not able to handle the context which changes over time for example initially I was working in MongoDB and now have moved to Postgres. This info either you have to modify in md manually or both the statements will appear before the llm.

MD file will keep all data points equally weighted which is not correct and it will also be unable to fetch the related data from the data point being fetched !

It strikes me as funny how we want to get super AI inteligence but keep trying to anthropomorphizing all AI aspects to make it more "human". IMHO, if we keep doing it we will create Human AI with all errors and deficiencies humans have.
hahaha, that's true. Intelligent and human may not be efficient, as humanity is much flawed by design
I only use a decay function to see how "hot" a chunk is - not for forgetting old ones. What concerns me more are memory chunks with errors in them - they need to be corrected/removed by some other mechanism, not by decay (since they might get retrieved often).
I am also building a similar memory structure and decay mechanism for my local agent project, where I also use Ebbinghaus. One of the challenge I face is how to decide effectively what to save in the memory: Is it the model to decide what is important, summarize and save it to the memory? How to avoid redundancy and categorize the memory correctly so you could get the right hit and decide what to forget. I would love to learn more about your approach and what your thoughts on those points
I planned and supervised the build of an ambient recall system, where a 4b model looks at the last 3k or so of context and picks through the RAG database for high ranking memories to inject, as well as mineable things to mark. Injections happens about 1/5 turns on most technical topics, data picked from prior design docs and data sheets mostly. At session wrapup the inference model goes back and rates all the memory injections in a frontmatter section, then looks at all the memory suggestions to commit those it finds memorable to the RAG database. Manual memorisation and RAG search are also available inline in the chat to both the user and the model. It also allows the main model to spawn little models as minions to work on repetitive simple tasks.

Seems to maybe be useful but I’m not sure yet.

It's the cumulative weighting based on the softmax output? Is it per layer?
No it's not based on softmax output. It's single pass for now !
Not something I've (yet) pursued, buy I did wonder a few days back if there was a good analogy between context window and short term memory, and storage with long term memory, and if so might an anki-like algorithm lead to better contexts by keeping relevant / difficult "memories" for the AI fresher (via spaced repetition), in an efficient manner.
Everyone and their pet dog is making longer term memory systems at the same time, and they all seem kind of meh. Not casting aspersions here, my own attempts all crash and burn too. And better than nothing is still better than nothing.

Thing is, this seems like it might be a Hard Problem of some sort. Everyone trying, no one making a clean breakthrough, I feel like it's some sort of smell. Either the desired function isn't well understood, or there's something missing, or it's in some weird complexity class, or ... something. My spidey senses tingle.

I wonder if others have the same feeling?

A different axis that holds up: a tiny always-loaded index pointing at per-fact files that load on demand. Claude Code's auto-memory uses this. The part that does the work isn't the lookup, it's the index itself acting as a filter. Every new fact has to summarize into one line that earns its keep, or it doesn't get saved. Stuff that misses the bar either gets rediscovered during work or wasn't load-bearing. 52% Recall@5 from forgetting is a real research win, but the production lever has been bounding the always-loaded set, not scoring what to forget
Hi all builder here, quick update. Benchmarked it against LongMemEval dataset and got the result 84.8% for recall top 5 and 86.8% for nDCG any@5. All the methodology and results are mentioned in the repo !
Also if any of you are curious on how to set it up. You only need to execute these 2 commands

pip install yourmemory yourmemory-setup