Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- 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.
by nsingh2 - Memory is not necessarily a good thing. What we need is a combination of sufficiently large context windows (10-100 million tokens) along with curate, bloat-free data.
- 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.
by 2001zhaozhao - 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.by guhcampos
- I'm looking in the same space: have you found anything else you're considering beyond OpenViking?by strix_varius
- 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"
by pianopatrick - Attention is all you need.
Seriously, isn’t this the core premise of RAG / modern embedding search systems?
by LPisGood - You can kludge it together by having the agent keep a log of what it does with any notes and lessons about friction / efficiency, and then on some interval review that + session history for items worth promoting into a topic-based memory, or for things that are needed constantly into the main AGENTS.md or a separate MEMORY.md that's loaded into every session. Reviewing the notes at the same time as session history helps provide enough context to make directionally correct decisions about what is worth keeping in context for future sessions.by hedgehog
- 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)
by ltsSmitty - 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.
by _bobm - > A memoryfield page looks like this:
So basically recfiles[1], and an entire suite of tools replaced by fopen and sed. Anyone who doesn't know of recfiles is doomed to reimplement it(poorly).--- 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...by kelseyfrog - Thanks for pointing out recfiles. I was not aware of it and will investigate whether we can reuse anything. That said Markdown with YAML frontmatter is not exactly my own invention!by calpaterson
- "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".
- A whole lot of text to say "Just use text".by thm
- That's only half. It's a while lot of text to say "it's markdown + RAG/semantic search".
The markdown explanation I was also unimpressed with, but RAG over hyperlinks is convincing to me.
by wasabi991011 - It feels like 50% of AI "progress" is just finding different ways to say "tell the model things in English."by andyfilms1
- 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.
by nzach - 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.
by 2001zhaozhao - we want some kind of fractal knowledge graph. It starts coarse at some zoom level and you can move in and out. You can insert knowledge at any level and it's out/in levels adjust accordingly. The search semantics at every level are the same, but whats in the visible area changes based on what your focus is.
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.
by cyanydeez - 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.
by DanielHB - 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.
by morelandjs - 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.
by dataviz1000 - 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.
by jjice - Memory is prone to poisoning. Also, I want to be able to take my toys and go elsewhere.
My method is seven layers of files, administered differently: meta-knowledge, project seed, LLM wiki, code, tickets and todos, chat logs, artifactory. Ordered idea-to-reality. All git repos. That outgrows any context window pretty soon. My way out of that trap is to use links, both wiki links and git permalinks.
by gritzko - This is why I created: https://github.com/alisorcorp/warrant
It keeps documentation from going out of date by embedding re-runnable verification checks directly inside markdown files (that the agents use, not humans). I use it with a handoff workflow to force Claude/GPT to re-verify facts before handing off documentation to the next session.
by pwython - 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...
by calpaterson - 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 doesn’t consistently apply them you can’t know the agent will make the correct choices.
You need memory of these important facts to avoid this expense or potential incorrectness. Memory does not itself scale though, without maintenance and pruning, and that has its own impacts on cost and correctness like the Chat memory.
“Damned if you do, damned if you don’t” at least until the agent can itself maintain its memory accurately - or some other non-human effort can achieve that.
by threecheese - 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.
by benslavin