Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Agent memory as a file format

calpaterson.com

Post reply on HN
Print view View original

91–100 of 115 posts

Re: Agent memory as a file format

#91

Post by _bobm »

I think this is the wrong approach because everything is external to the model. You end up creating an ad-hoc externalized model scaffolded out of coarser systems, RAGs, files, and so on.

This leads to, if useful at all, to this process of ad-hoc recall inference which has to happen in time. By itself this is not a problem.

The problem is that the model has to be constantly injected in context with the newest version of the "memory state" at each turn or relevant turn.

The newest coherent memory state is also a problem. More or less 50 years of not failures, but not success either. This may be even deeper problem than the externalization problem.

I think we are just in the very beginning and we are slapping database stuff to the transformer hoping it will work, but these deep neural-net architectures categorically show that they are not databases.

There will be a synergistic middle ground, but its shape is still not clear.

Re: Agent memory as a file format

#92

Post by 2001zhaozhao »

If the counterargument to knowledge graph-based memory systems is that they're slow and take multiple steps, then it's not really a counterargument. I'd happily trade off speed for giving the agent ability to find more precise memories.

That said, I think this article's basic idea of "text files + semantic search index" is a good way to implement memory because AI is already good at search, and semantic search is far more flexible than a knowledge graph and decreases the chance of the agent simply not being able to find a memory (or inserting duplicate memories, etc.) due to deciding to go into a slightly different branch than the one it needed to travel.

That said, I'd probably layer additional steps on top for further efficiency improvements. For example, automatic concise summaries of memory items, other supplemental indexing methods for better memory recall, etc. My ideal solution would be multi-step and therefore wouldn't solve the knowledge-graph's slowness, but it would solve the rigidness problem of a knowledge graph.

Re: Agent memory as a file format

#93

Post by 2001zhaozhao »

nzach wrote: post #43

I'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…

It's really about storing institutional context and on-task learnings. The AGENTS.md can do the same thing as memory, but if you have a good memory system, in theory you never need to do any ongoing maintenance of AGENTS.md and the system will do it automatically. And because it's automatic and has a whole harness system built around maintaining the memories, you can engineer it to have not just more convenience of maintenance but also better correctness / recall quality.

Memory systems can also let AI load memories on demand so it's actually analogous to maintaining AGENTS.md plus twenty different "read this if you need to do X" markdown files.

I think the name "memory" makes sense given that the AI system is one singular system with central context (rather than a software org of multiple distinct humans with distinct memories), so the equivalent of institutional knowledge in the software org really is just akin to memory for the AI system.

Re: Agent memory as a file format

#94

Post by edgyquant »

root_axis wrote: post #89
edgyquant wrote: post #88

Earlier quoted context omitted.

How does it sound like rag exactly? Rag queries a database and injects the results memory doesn’t do this

"text based index" is just another way of saying "database".

No it isn’t? There is no database and no querying for specific words. An llm reads a big ass block of text and determines if any of those lines are applicable, that is nothing like a database being queried

Re: Agent memory as a file format

#95

Post by DarmokTanagra »

phoghed wrote: post #48
DarmokTanagra wrote: post #33

Earlier quoted context omitted.

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

vector search with cosine adjacency works the best ime

Re: Agent memory as a file format

#96

Post by zackify »

dataviz1000 wrote: post #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 stru…

No memory. No web search 99% of the time.

Two agent.MD files that are very small. One on each project. One at parent project level.

Did 30M tokens through glm 5.3 flash today for 52c

Using pi and a few extensions my initial context is always 4k max

Re: Agent memory as a file format

#98

Post by mofosyne »

Instead of having to regenerate a zip file everytime you add/delete a memory... could we just use a git repo of markdown pages?

This buys you incremental writes, commit hash pinning and diffs for free. In addition to having a git archive outputting a zip export as well?

Main wrinkle is you would need to gitignore the sqlite database as it doesn't store very well in git (binary, changes lots per insert). But it's easy to regenerate anyway as a rebuild-able cache.

Re: Agent memory as a file format

#100

Post by artyomsv »

docheinestages wrote: post #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. No…

Cheapest version of that review is already sitting in the format. Frontmatter carries created and updated, so you can sort by staleness and drop whatever nothing touched in months
Post reply on HN