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…
Agent memory as a file format
81–90 of 115 posts
Re: Agent memory as a file format
#82That's a whole lot of text to say "it's markdown".
It feels like 50% of AI "progress" is just finding different ways to say "tell the model things in English."
But it's still text. You show people how the sausage is made and either they're confused or they're horrified.
Re: Agent memory as a file format
#83I'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…
One way I've toyed with a graph outline with it using "whitening" (https://arxiv.org/pdf/2104.01767v3) for embeddings rather than just text, so you add things like file path, nearest title/method/const etc. You have to have dummy text though because it fails with "null"; all embeddings need to carry some kind of text and of the same size.
so when the agent rembembers something, the memory would be an embedding that includes where they found the file, what method or const or whatever they're in, what the task they're working on is, etc. That all becomes a single embedding. You could imagine a metadata tag that also describes the tools they're using etc.
Map out a complete space of tags for whitening an embedding and there's surely a proper mix. Then when you're searching for things in the embedding, you also store some of the other metadata as plane strings & edges, which gets you some useful granularity.
Re: Agent memory as a file format
#84Re: Agent memory as a file format
#85Does 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…
Re: Agent memory as a file format
#86Earlier quoted context omitted.
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 int…
This is a real problem, and it’s not just in markdown files and docs. Claude loves to write things we’ve “discovered” in comments and then later in treats the comments as gospel truth. You have to constantly tend the garden and weed these things out. Whenever Claude makes some error ask it where and why? And then dig out the weed. And of course if it’s in the context, probably time for a handover doc (which will need…
There's a simple fix for this: do not let it write comments. Ever. This also has the nice property that there's much less AI slop to clean up afterwards.
Re: Agent memory as a file format
#87Does 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…
Re: Agent memory as a file format
#88Earlier quoted context omitted.
Memory isn’t the same thing as rag it’s usually just a text based index of past events and the llm reads it and decides what’s important rather than querying a db
Sounds like RAG to me.
Re: Agent memory as a file format
#89Re: Agent memory as a file format
#90Does 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 memory disabled in all my Chat UIs (even though it tends to creep in, looking at you ChatGPT). It’s very helpful until it scales with time, at which point it becomes useless due to staleness or mis-application across contexts. That being said, in coding over a longer time horizon, having the agent continually re-derive decisions/laws/facts/etc from your code is wasteful of tokens and time, and if your code doe…
e.g. docs/decisions/README.md (index with a blurb about each decision), docs/decisions/01-some-lesson.md (some architectural decision/pattern that you or the agents discovered).
ADR files have important sections like "rejected solutions" and "acceptable risks", and they're live files that can be refined and pivoted over time or retired to docs/decisions/archive/.
It's also nice to give each top-level bullet point some stable ID like "R1" for rejected solution #1, I3 for invariant #3. Agents use this stuff intelligently all the time like "This could be a time to reconsider D4/R2" = ADR #4, rejected solution #2.
The essential part being that your system ratchets into increasingly better decisions and invariants over time, and there's a place to actually put this stuff.
It's essential for automating high-quality software and something we couldn't be arsed to do much less update before AI.