Wouldn't Avro or Parquet be solid choices for something like this, or am I out of date & out of touch?
[dead]
Agent memory as a file format
41–50 of 114 posts
Re: Agent memory as a file format
#42Does anyone else not use memory? I find once there is one poisoned line of text it negatively affects everything else downstream. Instead, I use a temp/ folder with documents and use different files for different agents and models. Then I have to constantly prune and delete the files. Any information that can be extrapolated is just noise which negatively affects the agent. If you have a definition of a database stru…
I have mine self record into Supabase for my projects and a local sqlite for work. It determines a method of record keeping which I audit every week to hone the process. Really makes it so I can move to any provider I want and I have a queryable memory store. Also really helps when someone asks about why some feature was implemented a certain way. I also have it learn from corrections in PRs and comments made overtim…
> It determines a method of record keeping which I audit every week to hone the process
I would like to hear more details of what it ended up with for a structure
Re: Agent memory as a file format
#43I'm starting to think that 'memory' may be the wrong analogy for what we want.
I do think that having a set of token that are highly personalized to your project and to way you work is beneficial. I also think that the idea that this set of token will be constructed in the background without any work from the user is really appealing. So it's understandable that the 'memory' analogy became so popular.
But in my experience having a really good AGENTS.md file almost always produce better results than enabling memory.
Maybe we should start to think about how we 'train'/'onboard' agents into our projects, in a similar way that we do for new co-workers. Imagine if we could send the agent to our repo and ask it to learn our patterns and in the end we could quiz the agent to gauge how much it actually understood the project. Once he 'understands' the project we can start to use it to help with development.
In a very small scale (example, individual new features) I will sometimes ask the agent to explain me how things work (even though I already know how it works) so I can 'prime' the agent context with good data before starting any real work. But I'm not sure if this approach could be reliably scaled to work with any repo for any kind of work.
Re: Agent memory as a file format
#44Does anyone else not use memory? I find once there is one poisoned line of text it negatively affects everything else downstream. Instead, I use a temp/ folder with documents and use different files for different agents and models. Then I have to constantly prune and delete the files. Any information that can be extrapolated is just noise which negatively affects the agent. If you have a definition of a database stru…
Your experience mirrors my own. I don't know if he coined the term, but Steve Yegge talks about 'heresies' that creep in to a system -- untrue things that stick around and permanently influence its behavior. I still find that these happen regularly and stopped using self-managing memory systems because they make heresies even harder to diagnose and remove.
Within projects, I make heavy use of path-scoped rules to intentionally bring context where it's needed, and also make heavy use of temp directories. LLMs are more than happy to produce ad-hoc memories/summaries/context docs that I can then point a session to, but I can be selective and intentional about it.
I like that memoryfield is portable, intentional and composable. I'm not convinced that sharing memoryfields between users will be practical, but I keep isolated virtual environments for absolutely everything. I like the idea of being able to intentionally bring collections of managed context around with me. There are other ways to do that, but will keep an eye on this.
Re: Agent memory as a file format
#45I'm starting to think that 'memory' may be the wrong analogy for what we want. I do think that having a set of token that are highly personalized to your project and to way you work is beneficial. I also think that the idea that this set of token will be constructed in the background without any work from the user is really appealing. So it's understandable that the 'memory' analogy became so popular. But in my exper…
When I was doing a really large refactor across the codebase I told Claude Code to explain how certain things worked currently and how I wanted things to look like after the migration and a plan on how to get there. Then I did several further clean sessions where I always started along the lines: "Using this plan {link} do X."
Works pretty well for "non-permanent" instructions (you don't want to put this info into your committed markdowns).
My main motivation was simply to save tokens, but it actually worked really well and improved speed as well.
Re: Agent memory as a file format
#46Earlier quoted context omitted.
If you look at how agents navigate source code, they do not look at directory names, and drill down into the ones with plausible names, instead the grep the whole repo for plausible keywords. Of course, ideally your data would be structured, but the agents will mostly be grepping anyway, and maybe look at sibbling files.
its the same way they crawl websites, its horribly inefficient
[deleted]
Re: Agent memory as a file format
#47How well does it work in practice?
Re: Agent memory as a file format
#48Earlier quoted context omitted.
They already have. The tool is called bash and optimized api is grep, the storage is the file system. We’ve been here many months. What people are exploring are other options as far as I can tell. What you are offering is “don’t do that, this already works”. Which I guess is fine, but apparently not everyone is fully satisfied with the current generation of tooling.
I was responding specifically to the parent comment that was suggesting generating ad-hoc sql. Also fwiw grep is pretty poorly suited to semantic search and will only return the most basic of matches. If you are really trying to build a useful memory search tool there are much better options than plain text search.
Yeah but probably the whole of the memories for any given project will likely fit into context, and the agent can’t extract whatever it wants for the given task. Grep only comes in if they choose to narrow down the candidate memory files, and they are usually searching many keywords and synonyms.
Of course a real search system with ranking and whatnot would be better, but you’re paying a different cost there.
I’m personally more interested in how the memory files get created and updated and generally managed, retrieving the correct ones doesn’t seem to be a big problem at the moment.
I primarily use gh copilot and they are by default hidden from the user. It’s also not great that they aren’t in the repo and every contributor has their own set of memories of different freshness, likely conflicting.
Re: Agent memory as a file format
#49It’s good that a lot of people are trying a lot of things when it comes to agentic memory. Sadly none of it represents a complete solution at this time. But we need the experimentation.
I still dont understand what "agentic memory" is . agents can already call sql / rag and grep through files or whatever. why is "agentic memory" a special thing.
Agents have to decide to search files, and they don't always know that they should. For example, if the agent sees the database, it may miss detailed instructions on how to access the database deeper in the repo. Behaviorally, humans want to be able to say "hey, here's how to access the DB. Remember that." Or better yet, for it to happen automatically.
That's agentic memory.
Re: Agent memory as a file format
#50[flagged]