alt Hacker NewsAgent memory as a file format
Comments
Was ready to write something snarky because this is essentially RAG, but I think the author is getting at some subtle details which are seemingly important.
- memory systems are a specific type of knowledge base where you generate all the documents. You might as well generate them to be less than your embedding token limit to obviate the need for chunking.
- embedding models are getting better and are no longer just semantic averaging.
- small models are getting dirt cheap, making parallel reads cost manageable
What they describe is sort of the simplest architecture that takes advantage of these observations. I believe them when they say it works well.
I do suspect though that things like keyword lookup will completely fail if every memory is just a vector. Hence why something like Typesense hybrid search can still be useful.
"Irrelevant material is simply never surfaced by the semantic search." thats quite optimistic. there's lots of "memory" or past chats with agents that should be suppressed and forgotten because they were looking in the wrong place or were eventually proven wrong. yet semantically they'd look very relevant to a future search. thats why you shouldn't search both textbooks and scifi when trying to solve an examination.
That's a whole lot of text to say "it's markdown".
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 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.
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.
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.
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.
I think eventually you need some kind of system that ranks pieces of data based on how useful they are.
I.e. for the web we did that with link count etc.
We need some other mechanism for judging and ranking pieces of "memory" for "agents"
Separating declarative facts from active execution skills definitely helps prevent the prompt-drift loop. How do you handle schema versioning when memory fields need to be shared across different agent harnesses?
This was a compelling writeup to me. I read through the spec and found it easy to understand and make sense of.
I wonder how much my system needs something like this. Between the invisible system memory of my random chats with Gippity, my Matt Pocock skills saving terminology and plans, and whatever else Cursor and Codex do, I don't think I feel a need for more agent memory. I do like how it's exposed and searchable, and not invisible. But I honestly just send my questions/tasks away to my magic agent and eventually it gets it right anyway; do I need more discrete memory my team has to maintain? (That's an earnest question, not disregard for this)
What the author suggests is remarkably close to the proposition of OpenViking. I've been testing a few memory solutions and OpenViking is one of my favorites so far.
The most important thing for a memory system is not only remember and recall or search, it is maintain, that including, merge, forget, update etc. That is how human's work.
I am on linggen.dev , that is the one make daily agent work easier.
All of this stuff seems like a band-aid solution. These things need to be trained ground-up to maintain and update persistent memory (maybe outside the context window?).
Also seems like a requirement for any sort of continual learning capabilities as well.
It occurs to me: we have latent embedding giving 'general knowledge' to an LLM. What if we use a 'blank' LLM as well as an agent and train that blank LLM on personal context to query that as memory?
I think the simplest solution is just directory with md files and https://github.com/BeaconBay/ck
This mirrors my experience:
- Store session turns in an sqlite-vec
- Provide the agent with an mcp to search the vec-db
- Let the agent write notes in md files along with an index / frontmatter
Along with the commit history, the vec-db gives the agent long-term memory. The notes allow the user to correct accumulation of false lessons.
Simpler but better.
It’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.
Wouldn't Avro or Parquet be solid choices for something like this, or am I out of date & out of touch?
Memory is not just a matter of retrieval, it's also a matter of knowing what to retrieve and when.
It could also be shareable?
I just had a thought about similar thing - how to track human decisions on the codebase? Consider you are writing code together with AI, how you understand which code change happened because human asked for it
I've come to a similar lofi solution for my agent fleet. Markdown wiki with simple querying is decently effective as a memory system. Setting up a skill that can effectively reduce a session into useful long term lessons is the easiest unlock for these systems.
> A memoryfield page looks like this:
---
title: Carbon Fibre Woks
created: '2026-03-01T09:00:00Z'
updated: '2026-08-22T14:30:00Z'
uuid: 6aa615f0-486f-48a7-a210-ba4f5ff18c8b
summary: Thermal properties of carbon fibre cookware
---
Carbon fibre woks conduct heat evenly, but...
I'm not convinced an unstructured collection of memory files is the way to go at all.
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.
I see a lot of claims in this article without ... any proof?
Both can be true: - It's useful to anthropomorphize agents when predicting behavior and - we have to use specific language to specify what we mean.
What does the author mean by "confuse the models" ? Are they talking about not picking right information? Picking the wrong information? Losing their previous context / task?
Part of setting up a proper eval is also deciding what we actually mean ourself. What are we actually optimizing for? It's not, e.g. % confusion, %rubbish, etc.
The article does point to it: retrieval latency, accuracy, etc.
Are embeddings useful for something of the scale compared to just keyword search (aka grep)?
> Markdown "pages", with
> (optional) YAML frontmatter and
> (optional) SQLite vector index for semantic search
This is basically exactly what I use in a MCP service I built and it works pretty well. Can be enriched further if you use a storage system like S3 and take advantage of metadata.
"harness managed" memory is utter garbage, I am convinced, and I disable it immediately. The major problem being over time it degrades and sneaks in conflicting or outright false information. Then one day you'll swear it's drunk, and every time I got to this state and investigated, auto managed memory was always the problem.
the new OpenAI spec is agent memory as file names
How well does it work in practice?
> 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.
[flagged]
[flagged]
[flagged]
[dead]
[flagged]
[flagged]
[flagged]
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.