Live data from Hacker News

Agent memory as a file format

calpaterson.com

21–30 of 114 posts

Re: Agent memory as a file format

#21
> How can I judge what is a good memory to store? How can I avoid filling my memory with crap?

> This is a common fear with memory systems but doesn't really apply to memoryfields. Irrelevant material is simply never surfaced by the semantic search.

This is so wrong. The Achilles' heel of this approach is the RAG. What makes it worse is having lots of memories that are outdated, wrong, hallucinated, or irrelevant.

Nothing beats curated data. Memory should be regularly reviewed, compacted, and cleaned up if it's no longer valid.

Re: Agent memory as a file format

#22
post #3

I'm not convinced an unstructured collection of memory files is the way to go at all.

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

Re: Agent memory as a file format

#24
post #7

Agent memory is to computer memory is what Mongo DB is to relational database. Incredible to watch things come full circle. Next thing you know, someone is going to figure out a binary encoding.

agents can call relational databases fine. infact, really good at sql if you can store your memories into that format.

that sounds horribly token inefficient, just create a tool call if you are all in on the agentic approach and hide memory retrieval behind an optimized api

Re: Agent memory as a file format

#25
Does 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 structure and it has been implemented, that information should not be contained in any text document -- it is noise, will drift, and be impossible to debug why the agent keeps producing undesired behavior.

I have a ~/Projects folder. For example, I use Playwright with Chrome DevTools Protocol in order to do performance testing and leak detection. There is a script that handles this. My prompt is "Search ~/Projects for perf testing with CDP and Playwright and implement here". Point being, if I need anything I point to a resource or ask to search a resource and it will find it quick and, most importantly, tends to improve it every iteration.

If I was in an institution, I would have a repository and would rather just point the resource and say use that than have memory of it locally.

Re: Agent memory as a file format

#26

Earlier quoted context omitted.

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.

they just want to reinvent information retrieval from first principles; also the fact that everyone forgets to check what currently exists and reinvents hexagonal wheels for the sake of agentic development

Right now you have an opportunity to enlighten everyone rather than talk down to them.

Re: Agent memory as a file format

#28

Earlier quoted context omitted.

agents can call relational databases fine. infact, really good at sql if you can store your memories into that format.

that sounds horribly token inefficient, just create a tool call if you are all in on the agentic approach and hide memory retrieval behind an optimized api

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.

Re: Agent memory as a file format

#29

Does 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 keep it on for my web chats, but I think I dislike it more than it helps. I'll ask a question about something and it'll find a way to tie it back to something from three months ago thinking it was a deep project I was working on, instead of what it really was: an inane question I was curious about.

I turn it off for local agents because I bounce around a few and I really don't like the mostly implicit nature of it. I want to write my instructions in version control if I have anything to say consistently to an agent.

Re: Agent memory as a file format

#30

Does 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…

What I propose is only a very slightly more formal version of what you describe.

Just to start with: memoryfields are possible to use in a server/client system. That was a key aim and I do already use them over Amazon S3 (though not always).

I started, like you did, with a personal library of prompts. But the issue is that as your library of little pieces of prompts increases a) you get tired of constantly editing them yourself b) you have no easy way to export and share them with others c) it's frustrating that the agent doesn't "automatically" find your little bit of prompt on X even when clearly it is relevant - hence sem search.

I think a lot of people are still using the "personal library of bits of prompt" model. It is ok. But I wanted to propose an minimal, interchangeable standard for sharing them. So the idea of being an institution and having a shared memoryfield: that's something I want as well!

The spec, feedback greatly welcome:

https://github.com/calpaterson/memoryfield-spec/blob/main/SP...

Post reply on HN