Platform memory is locked to one model and one company. Stash brings the same capability to any agent — local, cloud, or custom. MCP server, 28 tools, background consolidation, Apache 2.0.
LLM Memeory (in general, any implementation) is good in theory.
In practice, as it grows it gets just as messy as not having it.
In the example you have on front page you say “continue working on my project”, but you’re rarely working on just one project, you might want to have 5 or 10 in memory, each one made sense to have at the time.
So now you still have to say, “continue working on the sass project”, sure there’s some context around details, but you pay for it by filling up your llm context , and doing extra mcp calls
Well the project is promising something without providing any details how exactly this is achieved which to me is always a huge red flag.
Digging deeper I can see it is effectively pg_vector plus mcp with two functions: "recall" and "remember".
It is effectively a RAG.
You can make the argument that perhaps the data structure matters but all of these "memory" systems effectively do the same and none of them have so far proven that retrieval is improved compared to baseline vector db search.
Isn’t “memory” just another markdown file that the LLM reads when starting a new session?
I keep two files in each project - AGENTS (generic) and PROJECT (duh). All the “memory” is manually curated in PROJECT, no messy consolidation, no Russian roulette.
I do understand that this is different because the vector search and selective unstash, but the messy consolidation risk remains.
Also not sure about tools that further detach us from the driver seat. To me, this seems to encourage vibe coding instead of engineering-plus-execution.
Not a criticism on the product itself, just rambling.
If I am working on a real project with real people, it won’t have the complete memory of the project. I won’t have the complete memory. My memory will be outdated when other PRs are merged. I only care about my tickets.
I am starting to think this is not meant for that kind of work.
I’m certainly on the lookout for something like this and I’m happy to see your account has published software from before the LLM boom as well. I guess I’d like some kind of LLM-use-statement attached to projects: did you use an LLM to generate this, and if so, how much and what stages (design, build, test)? How carefully did you review the output? Do you feel the quality is at least what you could have produced by yourself? That sort of thing.
Not casting aspersions on you personally, I’d really like this from every project, and would do the same myself.
I’m sorry this sounds a bit too entitled - no one is putting a gun to your head to use this project and you know you can always read the code and review it yourself and make an educated decision on whether you want to use it or not
I still haven't found useful "memory". It's either an agents.md with a high level summary, which is fairly useless for specific details (eg "editing this element needs to mark this other element as a draft") or something detailed and explaining the nitty gritty, which seems to give too much detail such that it gets ignored, or detail from one functional area contaminates the intended changes in another functional area.
The only approach I've found that works is no memory, and manually choosing the context that matters for a given agent session/prompt.
Even as someone highly interested in memory I don’t see it as a useful tool for coding. The source of truth for what a repo does or should do is the repo itself.
What you’re describing sounds more like code review guidelines, which can be explicitly brought into context at specific times during a change. A memory system is both too complex and less accurate for this
1) An up-to-date detailed functional specification.
2) A codebase structured and organized in multiple projects.
3) Well documented code including good naming conventions; each class, variable or function name should clearly state what its purpose is, no matter how long and silly the name is. These naming conventions are part of a coding guidelines section in Agent.md.
My functional specification acts as the Project.md for the agent.
Then before each agentic code review I create a tree of my project directory and I merged it with the codebase into one single file, and add the timestamp to the file name. This last bit seems to matter to avoid the LLM to refer to older versions and it’s also useful to do quick diffs without sending the agent to git.
So far this simple workflow has been working very well in a fairly large and complex codebase.
Not very efficient tokens wise, but it just works.
By the way I don’t need to merge the entire codebase every time, I may decide to leave projects out because I consider them done and tested or irrelevant to the area I want to be working on.
However I do include them in the printed directory tree so the agent at least knows about them and could request seeing a particular file if it needs to.
The traditional cursor is so 2025. It's predictable. Familiar. old.
AI is the future, so we need cursors of the future that simulate the frustrating lag and imprecision of LLMS. Dots chase other little dots around and do inscrutable little animations.
Actual answer: You need javascript to see their dumb custom cursor.
I didn't read much of the page - just was scrolling a bit to see what the fuck that thing is doing, and that was more than enough to know that I'll never touch whatever those people are doing.
All these agent memory systems seem so simultaneously over and under engineered and like a certain dead end. I cannot imagine any reality in which this does not rot and get out of sync with what the latest model need. For the one time you build a payment provider how many session will be tilted towards thinking about payments because of the "don't use stripe" memory?
I've treated this as an information problem and wrote a small utility that explicitly does not store most things (https://github.com/skorokithakis/gnosis). Basically, the premise is that the things the LLM knows will always be there, so store nothing the LLM said, the code will always be there so the code-relevant things should be comments, but there are things that will be neither, and that are never captured.
When we create anything, what we ended up not doing is often more important than what we did end up doing. My utility runs at the end of the session and captures all the alternatives we rejected, and the associated rationales, and stores that as system knowledge.
Basically, I want to capture all these things that my coworkers know, but that I can't just grep the code for. So far it's worked well, but it's still early.
I have a bespoke memory system that I wrote myself and it avoids this problem entirely by making every memory a contextual search space. The “don’t use stripe” memory would only be recalled into context if the model was prompted to do something with payment processing.
What's worse is how obvious the author hasn't even used it themselves. Completely unproven memory layer. No due diligence - just a fancy marketing site with outrageous claims
It's not clear to me how or why this works, and how it compares to just using md files in my project. For something like this, we really need benchmarks.
I clicked this thinking “oh, cool, someone finally made a portable version of the Claude.ai* memory system!”
Spoiler, no, it’s not it at all, it’s just a “store”/“remember” memory system… as opposed to the Claude.ai memory system, where it doesn’t make the model actively have to write memories on its own, but rather has a model in the background go through your chat history and generate a summary from it.
I’ve found the latter approach to work much, much better than simple “store”/“remember” systems.
So, it just feels misleading to say this can do what Claude.ai’s can do…
(I’ve been looking for a memory system that works the same for a while, so that I can switch away from Claude.ai to something else like LibreChat, but I just haven’t found any. Might be the only thing keeping me on Claude at this point.)
-
*I say Claude.ai because that’s specifically what has the system; Claude Code doesn’t have this system
Shameless drop: My own agentic environment is also using a summarizer to sum up agent histories when they overflow in their context windows. Additionally, all short lived agents are based on requirements (WIP) as a centralized point for code, unit tests, and architecture.
(Everything is tailored to Go as a language)
Works pretty good so far, the user only interacts with the planner. I'm working atm on the requirements to have a spec driven workflow. Web UI is the most polished atm because of ability to have agent tabs on the side for better overview.
this is a patch on top of the broken flat-compaction caching algorithm used by coding agents. Why not fix the cache algorithm directly? Union-find is a better impl june.kim/union-find-compaction
I'd like to use this for our locally running game agent[0] but the PostgreSQL and other dependencies is a show stopper. Why so complex?
[0] Ziva.sh is a desktop app that brings agentic features to game engines. We can't just bundle a running DB and we won't be sending this sensitive info to a cloud
Now that building software is effectively free, it's astounding that we're still trying to pitch things like this using a vibe-coded fancy marketing site. Who has time to use these and wait weeks or months to find out if they actually work? There's no proof in the site this is better than RAG or even a folder of memory files and grep, yet makes all these fantastic claims (while scrolling at 14fps). This wasn't even coded 24 hours ago... It's honestly so lazy.
39 comments
[ 23.1 ms ] story [ 336 ms ] threadIn practice, as it grows it gets just as messy as not having it.
In the example you have on front page you say “continue working on my project”, but you’re rarely working on just one project, you might want to have 5 or 10 in memory, each one made sense to have at the time.
So now you still have to say, “continue working on the sass project”, sure there’s some context around details, but you pay for it by filling up your llm context , and doing extra mcp calls
There is lots of competition in this space, how is your tool different?
Digging deeper I can see it is effectively pg_vector plus mcp with two functions: "recall" and "remember".
It is effectively a RAG.
You can make the argument that perhaps the data structure matters but all of these "memory" systems effectively do the same and none of them have so far proven that retrieval is improved compared to baseline vector db search.
I keep two files in each project - AGENTS (generic) and PROJECT (duh). All the “memory” is manually curated in PROJECT, no messy consolidation, no Russian roulette.
I do understand that this is different because the vector search and selective unstash, but the messy consolidation risk remains.
Also not sure about tools that further detach us from the driver seat. To me, this seems to encourage vibe coding instead of engineering-plus-execution.
Not a criticism on the product itself, just rambling.
If I am working on a real project with real people, it won’t have the complete memory of the project. I won’t have the complete memory. My memory will be outdated when other PRs are merged. I only care about my tickets.
I am starting to think this is not meant for that kind of work.
Not casting aspersions on you personally, I’d really like this from every project, and would do the same myself.
The only approach I've found that works is no memory, and manually choosing the context that matters for a given agent session/prompt.
What you’re describing sounds more like code review guidelines, which can be explicitly brought into context at specific times during a change. A memory system is both too complex and less accurate for this
How does it fight context pollution?
1) An up-to-date detailed functional specification.
2) A codebase structured and organized in multiple projects.
3) Well documented code including good naming conventions; each class, variable or function name should clearly state what its purpose is, no matter how long and silly the name is. These naming conventions are part of a coding guidelines section in Agent.md.
My functional specification acts as the Project.md for the agent.
Then before each agentic code review I create a tree of my project directory and I merged it with the codebase into one single file, and add the timestamp to the file name. This last bit seems to matter to avoid the LLM to refer to older versions and it’s also useful to do quick diffs without sending the agent to git.
So far this simple workflow has been working very well in a fairly large and complex codebase.
Not very efficient tokens wise, but it just works.
By the way I don’t need to merge the entire codebase every time, I may decide to leave projects out because I consider them done and tested or irrelevant to the area I want to be working on.
However I do include them in the printed directory tree so the agent at least knows about them and could request seeing a particular file if it needs to.
AI is the future, so we need cursors of the future that simulate the frustrating lag and imprecision of LLMS. Dots chase other little dots around and do inscrutable little animations.
Actual answer: You need javascript to see their dumb custom cursor.
When we create anything, what we ended up not doing is often more important than what we did end up doing. My utility runs at the end of the session and captures all the alternatives we rejected, and the associated rationales, and stores that as system knowledge.
Basically, I want to capture all these things that my coworkers know, but that I can't just grep the code for. So far it's worked well, but it's still early.
I’ve found the latter approach to work much, much better than simple “store”/“remember” systems.
So, it just feels misleading to say this can do what Claude.ai’s can do…
(I’ve been looking for a memory system that works the same for a while, so that I can switch away from Claude.ai to something else like LibreChat, but I just haven’t found any. Might be the only thing keeping me on Claude at this point.)
-
*I say Claude.ai because that’s specifically what has the system; Claude Code doesn’t have this system
(Everything is tailored to Go as a language)
Works pretty good so far, the user only interacts with the planner. I'm working atm on the requirements to have a spec driven workflow. Web UI is the most polished atm because of ability to have agent tabs on the side for better overview.
In case anyone is interested in this attempt:
[1] https://github.com/cookiengineer/exocomp
How many are we up to now? Has to be hundreds of them.
Together with the other hundred llm memory systems: https://zby.github.io/commonplace/agent-memory-systems/
I have also written a wishlist for these systems: https://zby.github.io/commonplace/notes/designing-agent-memo...
[0] Ziva.sh is a desktop app that brings agentic features to game engines. We can't just bundle a running DB and we won't be sending this sensitive info to a cloud