HN user
I agree to your point, in our current system we are not treating each memory as same. Based on the importance, category and recall frequency we decide a decay rate which would not be same for all the memories. A architectural decision will have a higher importance and although if it's not recalled frequently enough, it will still have a slower decay rate.
The final artifact will look like a flat scored memory graph, in which each node will be a memory having threshold between 0-1 which will be derived through various parameters such as recall, importance etc. Edges will connect semantically similar memories
Repo Link : https://github.com/sachitrafa/YourMemory
So based on the importance that it gives the reports individual will decide that which report will survive in the system. You can manually also identify and set the importance or can let llm be the deciding factor here to assign weightage.
How would you know if the agent is not querying stale data here ?
Would be definitely trying this, how do you check the rollback of API calls which would not be an part of a transaction?
Sure will have a look !
Hi All,
Based on the feedback, have made few new enhancement. 1. Activity aware decay, now instead of a wall clock we run decay based on active days in which the user has been using the system. 2. Spatial/ Working directory memory, now while storing an memory we will associate the filePath or active directory and at time of retrieval boast memory associated to the working directory 3. Session wrap up boast, now at the end of a session we will count how many times a memory is being recalled n a session and will apply a recency boost. 4. Memory consolidation, periodically merge near duplicate memories into one combined memory instead of accumulating near identical facts. 5. Suppression link, now when update memory is called we will have a supresed by pointer from the old memory to the new one. This is to keep a track. 6. Smart recall throtelling, added an optional flag of recall cooldown so recall is not triggered in every singal turn. Useful when agents doing multi step task where context is already injected.
All the changes are avaliable in the latest version
pip install yourmemory !
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 !
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
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 !
No it's not based on softmax output. It's single pass for now !
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
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 !
Yes this is the way forward in CICD as we move more towards agentic ai development more and more, great project !
All memories should not decay at the same rate. these weights should be configurable !
What is this solving actually and how is this different from a private insta account ?
This is hilarious and oddly soothing. Tolkien is the ultimate stress test for long term context if the agent describes landscapes forever, how are you preventing it from looping or losing the "world state"? I’ve been obsessed with fixing agentic memory bloat lately, and an infinite Tolkien monologue is basically the final boss of context management.
The name could have been better
The CD-ROM streaming approach is the real insight here, keeping only activations and KV cache in RAM and streaming weights one matrix at a time sidesteps the 32MB constraint entirely. It's essentially the same trick modern edge inference does with flash storage, just on hardware from 2000. Curious about the latency profile, with CD-ROM read speeds around 1.6 MB/s on PS2, the 77MB SmolLM2 model being too slow makes sense, but how does the 10MB brandon-tiny feel in practice? Are you getting tokens per minute or more like tokens per several seconds? Also interested in the custom PSNT format decision, was the main motivation the PS2's MIPS alignment constraints, or was there something about the existing GGUF/llama.c formats that made them impractical to parse on the Emotion Engine?
The cross-realm argument for packages like is-string is the one I find hardest to dismiss, but even there the math doesn't add up. The number of projects actually passing values across realms is tiny, and those projects should be the ones pulling in cross-realm-safe utilities, not every downstream consumer of every package that ever considered it. The deeper problem with Pillar 2 is that atomic packages made sense as a philosophical argument but broke down the moment npm made it trivially easy to publish. The incentive was "publish everything, let consumers pick what they need" but the reality is consumers never audit their trees,they just install and forget. So the cost that was supposed to be opt-in became opt-out by default. The ponyfill problem feels most tractable to me. A simple automated check "does every LTS version of Node support this natively?" could catch most of these. The e18e CLI is a good start but it still requires someone to run it intentionally. I wonder if something like a Renovate-style bot that opens PRs to remove outdated ponyfills would move the needle faster than waiting for maintainers to notice.
The payments background makes total sense as an origin for this I've seen teams reach for Ray or Prefect and spend weeks configuring things they didn't need, when the actual problem was just 'how do I get work off this one machine cleanly.
One thing I'm curious about: what happens when a gRPC worker goes quiet mid execution?
Does the caller find out, or is it purely fire and forget? I hit a similar decision point building a memory layer for AI agents ended up skipping retry logic entirely because the coordination overhead just wasn't worth it for my use case. Wondering if you landed in the same place or have a different take.
Sub-millisecond dispatch locally is a good sign. The number I'd really want to see is how that holds up once you've got 20-30 workers in the mesh that's usually where the interesting degradation starts.