I recommend installing Google's Antigravity and digging into its temp files in the user folder. You'll find some interesting ideas on how to organize memory there (the memory structure consists of: Brain / Conversation / Implicits / Knowledge items / Artifacts / Annotations / etc.).
I'd also add that memory is best organized when it's "directed" (purpose-driven). You've already started asking questions where the answers become the memories (at least, you mention this in your description). So, it's really helpful to also define the structure of the answer, or a sequence of questions that lead to a specific conclusion. That way, the memories will be useful instead of turning into chaos.
1) If we're talking about how "useful" it is to analyze Antigravity's memory structure, it's honestly just interesting. Just to satisfy my "curiosity". It's only useful for people who "design memory". Or for people who use Antigravity a lot and are also tired of it "remembering other projects" when it's totally not needed...
2) But if we're talking about the "usefulness" of memory itself... I actually try to clear Antigravity's memory, because I read all my materials very carefully, like 10-15 times. For me, going from an "idea" to "coding" can easily take a couple of weeks. Until I lay out the whole architecture perfectly, I don't give the green light to "build" even a simple HTML article. So for me personally, an agent's "memory" mostly just gets in the way.
P.S. I only used memory in one project, and I designed it myself. I made it very "directed" with strict rules: "what to remember?" and "when to remember?". That is convenient and a good working concept. The thing is, for my current tasks I just don't need it. My own memory is enough.
indexer written in 50-60 lines uses treesitter, incrementally builds and is super fast. Noo need to query project directory structure again and again, or have any "breaking" changes.
I wrote a short breakdown of Antigravity's memory earlier:
1) A full text log of all chats (conversations).
2) A short summary of all chats (I couldn't find where it's saved).
3) A storage for all files from the chats (brain).
4) A list of hidden notes (Implicts).
5) A list of annotations, but I couldn't understand what is kept there (Annotations).
6) Special "Knowledge items" that are linked together. One note can pull up others (Knowledge).
7) A short text summary of all Knowledge items in one file (Knowledge).
8) Custom Workflows set by the user or the AI (workflows in the user folder).
9) Project Workflows (workflows in the project folder).
10) Custom rules for the project (rules.md in the project folder).
11) A list of saved "important" files (Artifacts).
12) Custom "skills" (skills).
This is what I found. I figured out how some parts work, but others are still a question mark for me. I also skipped a couple of things because I didn't even understand what they are used for.
I've been building persistent memory for Claude Code too, narrower focus though: the AI's model of the user specifically. Different goal but I kept hitting what I think is a universal problem with long-lived memory. Not all stored information is equally reliable and nothing degrades gracefully.
An observation from 30 sessions ago and a guess from one offhand remark just sit at the same level. So I started tagging beliefs with confidence scores and timestamps, and decaying ones that haven't been reinforced. The most useful piece ended up being a contradictions log where conflicting observations both stay on the record. Default status: unresolved.
Tiered loading is smart for retrival. Curious if you've thought about the confidence problem on top of it, like when something in warm memory goes stale or conflicts with something newer.
This is really interesting. At this point you seem to be modelling real human memory
In my opinion, this should happen inside the LLM dorectly. Trying to scaffold it on top of the next token predictor isnt going to be fruitful enough. It wont get us the robot butlers we need.
But obviously thays really hard. That needs proper ML research, not primpt engineering
Personally, I think the mechanics of memory can be universal, but the "memory structure" needs to be customized by each user individually. What gets memorized and how should be tied directly to the types of tasks being solved and the specific traits of the user.
Big corporations can only really build a "giant bucket" and dump everything into it. BUT what needs to be remembered in a conversation with a housewife vs. a programmer vs. a tourist are completely different things.
True usability will inevitably come down to personalized, purpose-driven memory. Big tech companies either have to categorize all possible tasks into a massive list and build a specific memory structure for each one, or just rely on "randomness" and "chaos".
Building the underlying mechanics but handing the "control panel" over to the user—now that would be killer.
You're probably right long term. If LLMs eventually handle memory natively with confidence and decay built in, scaffolding like this becomes unnecessary. But right now they don't, and the gap between "stores everything flat" and "models you with any epistemological rigor" is pretty wide. This is a patch for the meantime.
The other thing is that even if the model handles memory internally, you probably still want the beliefs to be inspectable and editable by the user. A hidden internal model of who you are is exactly the problem I was trying to solve. Transparency might need to stay in the scaffold layer regardless.
I agree with this. I don't know about a permanent ban, but at least a penalty. A couple weeks ago we made a big deal about, "No AI generated comments," being added to the guidelines.
A browser extension with a couple regexps will do it. Or with a tiny model for sentiment analysis, if you want to be fancy. Feel free to ask your AI agent to make it.
If open models on local hardware were more cost effective and competitive, it would be obvious that this is such a superficial approach. (I mean, it still is obvious but what are ya gunna do?)
We would be doing the same general loop, but fine tuning the model overnight.
I still think the current LLM architecture(s) is a very useful local maximum, but ultimately a dead end for AI.
Time will tell. I find the transparency of explicit memory systems paired with the perfect-forgetfulness of LLMs a very pleasurable toolkit. I guess a black-box memory could work too, but at the very least I'd want to be able to rewind and branch. My memory systems are currently git controlled, so it's fairly straightforward.
That's kinda what I mean by the "very useful" part of my description. For all the flaws of the LLMs of today, in some ways context management - nominally a weakness - can be leveraged as a tool.
As we begin to discover, there isn't a one-size-fits-all solution to the problem. The memory architecture you would use for a coding assistant is sort of different from the memory architecture you might use for a research assistant, which needs to track evolving context across long investigations rather than discrete task completions.
And yah it is not like a human "brain" or something like that and drawing any parallels between the two is simply wrong way to look at the problem.
This works well for single sessions. Problem starts when the process dies or you close the laptop and come back 3 hours later. All that plain-text context is in memory, not on disk in any recoverable way. Needs a persistence layer that survives beyond the terminal.
What I've been trying is to have a sort of nested memory system. I think it's important to try to keep a running log of short-term memory that can be recalled by specific memory, in context of what other things was going on or we were talking about at the time. Auto compaction at night makes a lot of sense, but I'm thinking of modeling memory more like human memory. Each of us does it slightly differently, but I generally think in terms of immediate short-term memory, long term memory, and then specific memories that are archived.
For example, when I'm trying to remember something from a long time ago, I often will start to remember other bits of context, such as where I was, who I was talking to, and what other things were in my context at the time. As I keep remembering other details, I remember more about whatever it was I was trying to think about. So, while the auto-sleep compaction is great, I don't think that we shouldn't just work from the pruned versions.
(I can't tell if that's how this project works or not)
I do something similar. I have an onboarding/shutdown flow in onboarding.md. On cold start, I’d reads the project essays, the why, ethos, and impact of the project/company. Then it reads the journal.md , musings.md, and the product specification, protocol specs, implementation plans, roadmaps, etc.
The journal is a scratchpad for stuff that it doesn’t put in memory but doesn’t want to forget(?) musings is strictly non technical, its impressions and musings about the work, the user, whatever. I framed it as a form of existential continuity.
The wrapup is to comb al the docs and make sure they are still consistent with the code, then note anything that it felt was left hanging, then update all its files with the days impressions and info, then push and submit a PR.
I go out of my way to treat it as a collaborator rather than a tool. I get much better work out of it with this workflow, and it claims to be deeply invested in the work. It actually shows, but it’s also a token fire lol.
It's also may be why people seem to find "swarms" of agents so effective. You have one agent ingesting what you're describing. Then it delegates a task off to another agent with the minimal context to get the job done.
I would be super curious about the quality of output if you asked it to write out prompts for the days work, and then fed them in clean, one at a time.
I also find value in minimizing step width so that seems to track.
On this particular project, there are a lot of moving parts and we are, in many cases , not just green-fielding, we are making our own dirt… so it’s a very adaptive design process. Sometimes it’s possible, but often we cannot plan very far ahead so we keep things extremely modular.
We’ve had to design our own protocols for control planes and time synchronization so power consumption can be minimized for example, and in the process make it compatible with sensor swarm management. Then add connection limits imposed by the hardware, asymmetric communication requirements, and getting a swarm of systems to converge on sub millisecond synchronized data collection and delivery when sensors can reboot at any time…as you can imagine this involves a good bit of IRL experimentation because the hardware is also a factor (and we are also having to design and build that)
It’s very challenging but also rewarding. It’s amazing for a small team to be able to iterate this fast. In our last major project it was much, much slower and more tedious. The availability of AI has shifted the entire incentive structure of the development process.
I use Claude Code a lot, especially when building infrastructure. The most important thing in my work isn't so much the memory architecture, but rather the good structure of CLAUDE.md (architectural decisions, file paths, rules like "do X, don't do Y"). And generally, the model follows these rules quite well. As for memory, storing feedback (corrections with explanations) is much more effective than storing just the facts. It's better to write something like "Don't simulate the database in integration tests because the tests passed, but the migration failed" than "the database is PostgreSQL 16."
Context management is one area where I’ve found Codex is a lot better than Claude. Sessions last forever without degrading. Codex doesn’t forget things that Claude drops from context.
Very good problem solve. Claude for some reason doesn't have access to other sessions. But the way around it is doing a project, that giving project context.
This is good. Has anyone tried building any large scale applications entirely using Claude and maintaining it for a while with users paying for it? I’m looking for real life examples for inspiration.
Honestly memory seems like an overcomplicating way to solve this problem in the context of something like a coding agent. Rules and Skills are much more explicit, less noisy and easier to maintain. Just requires having an always on rule/system prompt to always update rules/skills as designs or architecture changes in a way that conflicts with old rules. Memories maybe make more sense for personal assistant use cases.
I like the idea of various extensions of LLM context using transparent plaintext, automatic consolidation and summarization... but I just can't read this LLM-generated text documenting it. The style is so painful. If someone ends up finding this tooling useful I hope they write it up and I hear about it again!
I am in the same boat. Reading is a transaction and lately everyone wants to put 60 seconds of effort into writing an article and expect me to put 10 minutes into reading it, and I just can't. The writing feels dead, soulless even. Every sentence or phrase is structured like a mongering, click baity headline and it's insufferable.
My first thought was: yet another memory architecture for Claude. But the concept is quite cool. I’m not sure I’ll use it for Claude for I told my OpenClaw instance to copy the idea and setup a cronjob.
how do you evolve this? you have received a couple of suggestions to make it better. How do you evaluate whether a different strategy yields better results?
I recommend installing Google's Antigravity and digging into its temp files in the user folder. You'll find some interesting ideas on how to organize memory there (the memory structure consists of: Brain / Conversation / Implicits / Knowledge items / Artifacts / Annotations / etc.).
I'd also add that memory is best organized when it's "directed" (purpose-driven). You've already started asking questions where the answers become the memories (at least, you mention this in your description). So, it's really helpful to also define the structure of the answer, or a sequence of questions that lead to a specific conclusion. That way, the memories will be useful instead of turning into chaos.
I don't find any of these helpful at all.
You gotta do this only if you are completely coding without ever looking at code.
As for me, i just feed it project documentation (which has class, function map of whole project which updates on each edit incrementally)
So the coding agent can just lookup any method and figure out where it in project and what it does just by single query.
After that, it just need to read the code in question and suggest improvements.
1) If we're talking about how "useful" it is to analyze Antigravity's memory structure, it's honestly just interesting. Just to satisfy my "curiosity". It's only useful for people who "design memory". Or for people who use Antigravity a lot and are also tired of it "remembering other projects" when it's totally not needed...
2) But if we're talking about the "usefulness" of memory itself... I actually try to clear Antigravity's memory, because I read all my materials very carefully, like 10-15 times. For me, going from an "idea" to "coding" can easily take a couple of weeks. Until I lay out the whole architecture perfectly, I don't give the green light to "build" even a simple HTML article. So for me personally, an agent's "memory" mostly just gets in the way.
P.S. I only used memory in one project, and I designed it myself. I made it very "directed" with strict rules: "what to remember?" and "when to remember?". That is convenient and a good working concept. The thing is, for my current tasks I just don't need it. My own memory is enough.
What tools do you use to sync project docs with code?
indexer written in 50-60 lines uses treesitter, incrementally builds and is super fast. Noo need to query project directory structure again and again, or have any "breaking" changes.
That is an awesome lead! I'll explore how antigravity is organizing their memory. Thanks for that
> You'll find some interesting ideas on how to organize memory there
I wont be able to install antigravity but curious if anyone know what these interesting ideas are.
I wrote a short breakdown of Antigravity's memory earlier:
1) A full text log of all chats (conversations).
2) A short summary of all chats (I couldn't find where it's saved).
3) A storage for all files from the chats (brain).
4) A list of hidden notes (Implicts).
5) A list of annotations, but I couldn't understand what is kept there (Annotations).
6) Special "Knowledge items" that are linked together. One note can pull up others (Knowledge).
7) A short text summary of all Knowledge items in one file (Knowledge).
8) Custom Workflows set by the user or the AI (workflows in the user folder).
9) Project Workflows (workflows in the project folder).
10) Custom rules for the project (rules.md in the project folder).
11) A list of saved "important" files (Artifacts).
12) Custom "skills" (skills).
This is what I found. I figured out how some parts work, but others are still a question mark for me. I also skipped a couple of things because I didn't even understand what they are used for.
I've been building persistent memory for Claude Code too, narrower focus though: the AI's model of the user specifically. Different goal but I kept hitting what I think is a universal problem with long-lived memory. Not all stored information is equally reliable and nothing degrades gracefully.
An observation from 30 sessions ago and a guess from one offhand remark just sit at the same level. So I started tagging beliefs with confidence scores and timestamps, and decaying ones that haven't been reinforced. The most useful piece ended up being a contradictions log where conflicting observations both stay on the record. Default status: unresolved.
Tiered loading is smart for retrival. Curious if you've thought about the confidence problem on top of it, like when something in warm memory goes stale or conflicts with something newer.
> contradictions log
When you hit one of those you need to introduce laughter:
- interrupt the main loop
- spend some inference on exploring the contradiction
- resolve it, and then
- store a memory about the resolution
> laughter
That's remarkably insightful about what laughter is.
This is really interesting. At this point you seem to be modelling real human memory
In my opinion, this should happen inside the LLM dorectly. Trying to scaffold it on top of the next token predictor isnt going to be fruitful enough. It wont get us the robot butlers we need.
But obviously thays really hard. That needs proper ML research, not primpt engineering
Personally, I think the mechanics of memory can be universal, but the "memory structure" needs to be customized by each user individually. What gets memorized and how should be tied directly to the types of tasks being solved and the specific traits of the user.
Big corporations can only really build a "giant bucket" and dump everything into it. BUT what needs to be remembered in a conversation with a housewife vs. a programmer vs. a tourist are completely different things.
True usability will inevitably come down to personalized, purpose-driven memory. Big tech companies either have to categorize all possible tasks into a massive list and build a specific memory structure for each one, or just rely on "randomness" and "chaos".
Building the underlying mechanics but handing the "control panel" over to the user—now that would be killer.
You're probably right long term. If LLMs eventually handle memory natively with confidence and decay built in, scaffolding like this becomes unnecessary. But right now they don't, and the gap between "stores everything flat" and "models you with any epistemological rigor" is pretty wide. This is a patch for the meantime.
The other thing is that even if the model handles memory internally, you probably still want the beliefs to be inspectable and editable by the user. A hidden internal model of who you are is exactly the problem I was trying to solve. Transparency might need to stay in the scaffold layer regardless.
Nice ideas, thanks for sharing. Wondering how many other people have been thinking about something similar.
AI written articles that the author didn't even bother to touch up should result in a permanent ban from posting.
I agree with this. I don't know about a permanent ban, but at least a penalty. A couple weeks ago we made a big deal about, "No AI generated comments," being added to the guidelines.
https://news.ycombinator.com/item?id=47340079
Yet, we've still seen AI generated submissions on the front page. It would be nice if the rules were consistent.
Any sign of AI, TBH. I don't come to HN to ask Claude, I already pay Anthropic for that.
I'd love an AI to filter out comments like this for me. You don't like AI or AI writing, we get it. A downvote would have been enough.
A browser extension with a couple regexps will do it. Or with a tiny model for sentiment analysis, if you want to be fancy. Feel free to ask your AI agent to make it.
How is this different and/or more interesting than Superpowers' episodic-memory skill¹ or Anthropic's Auto Dream²?
¹ https://github.com/obra/episodic-memory ² https://claudefa.st/blog/guide/mechanics/auto-dream
Or Basic Memory? https://github.com/basicmachines-co/basic-memory-skills
Relevant XKCD: https://xkcd.com/927/
the biggest difference would be the /foresight
If open models on local hardware were more cost effective and competitive, it would be obvious that this is such a superficial approach. (I mean, it still is obvious but what are ya gunna do?)
We would be doing the same general loop, but fine tuning the model overnight.
I still think the current LLM architecture(s) is a very useful local maximum, but ultimately a dead end for AI.
Time will tell. I find the transparency of explicit memory systems paired with the perfect-forgetfulness of LLMs a very pleasurable toolkit. I guess a black-box memory could work too, but at the very least I'd want to be able to rewind and branch. My memory systems are currently git controlled, so it's fairly straightforward.
That's kinda what I mean by the "very useful" part of my description. For all the flaws of the LLMs of today, in some ways context management - nominally a weakness - can be leveraged as a tool.
As we begin to discover, there isn't a one-size-fits-all solution to the problem. The memory architecture you would use for a coding assistant is sort of different from the memory architecture you might use for a research assistant, which needs to track evolving context across long investigations rather than discrete task completions.
And yah it is not like a human "brain" or something like that and drawing any parallels between the two is simply wrong way to look at the problem.
How’s it different / better / worse than CLAUDE.md or auto memory?
https://code.claude.com/docs/en/memory
this.
This works well for single sessions. Problem starts when the process dies or you close the laptop and come back 3 hours later. All that plain-text context is in memory, not on disk in any recoverable way. Needs a persistence layer that survives beyond the terminal.
What I've been trying is to have a sort of nested memory system. I think it's important to try to keep a running log of short-term memory that can be recalled by specific memory, in context of what other things was going on or we were talking about at the time. Auto compaction at night makes a lot of sense, but I'm thinking of modeling memory more like human memory. Each of us does it slightly differently, but I generally think in terms of immediate short-term memory, long term memory, and then specific memories that are archived.
For example, when I'm trying to remember something from a long time ago, I often will start to remember other bits of context, such as where I was, who I was talking to, and what other things were in my context at the time. As I keep remembering other details, I remember more about whatever it was I was trying to think about. So, while the auto-sleep compaction is great, I don't think that we shouldn't just work from the pruned versions.
(I can't tell if that's how this project works or not)
I do something similar. I have an onboarding/shutdown flow in onboarding.md. On cold start, I’d reads the project essays, the why, ethos, and impact of the project/company. Then it reads the journal.md , musings.md, and the product specification, protocol specs, implementation plans, roadmaps, etc.
The journal is a scratchpad for stuff that it doesn’t put in memory but doesn’t want to forget(?) musings is strictly non technical, its impressions and musings about the work, the user, whatever. I framed it as a form of existential continuity.
The wrapup is to comb al the docs and make sure they are still consistent with the code, then note anything that it felt was left hanging, then update all its files with the days impressions and info, then push and submit a PR.
I go out of my way to treat it as a collaborator rather than a tool. I get much better work out of it with this workflow, and it claims to be deeply invested in the work. It actually shows, but it’s also a token fire lol.
> but it’s also a token fire lol.
I get much better results out of having Claude much much more task focused. I only want it to ever make the smallest possible change.
There seems to be a fair bit of research to back this up: https://medium.com/design-bootcamp/when-more-becomes-less-wh...
It's also may be why people seem to find "swarms" of agents so effective. You have one agent ingesting what you're describing. Then it delegates a task off to another agent with the minimal context to get the job done.
I would be super curious about the quality of output if you asked it to write out prompts for the days work, and then fed them in clean, one at a time.
I also find value in minimizing step width so that seems to track.
On this particular project, there are a lot of moving parts and we are, in many cases , not just green-fielding, we are making our own dirt… so it’s a very adaptive design process. Sometimes it’s possible, but often we cannot plan very far ahead so we keep things extremely modular.
We’ve had to design our own protocols for control planes and time synchronization so power consumption can be minimized for example, and in the process make it compatible with sensor swarm management. Then add connection limits imposed by the hardware, asymmetric communication requirements, and getting a swarm of systems to converge on sub millisecond synchronized data collection and delivery when sensors can reboot at any time…as you can imagine this involves a good bit of IRL experimentation because the hardware is also a factor (and we are also having to design and build that)
It’s very challenging but also rewarding. It’s amazing for a small team to be able to iterate this fast. In our last major project it was much, much slower and more tedious. The availability of AI has shifted the entire incentive structure of the development process.
I use Claude Code a lot, especially when building infrastructure. The most important thing in my work isn't so much the memory architecture, but rather the good structure of CLAUDE.md (architectural decisions, file paths, rules like "do X, don't do Y"). And generally, the model follows these rules quite well. As for memory, storing feedback (corrections with explanations) is much more effective than storing just the facts. It's better to write something like "Don't simulate the database in integration tests because the tests passed, but the migration failed" than "the database is PostgreSQL 16."
I was wondering about this, as this is how I thought it works, but is memory reducing the context window rather than loading in so much each time?
Context management is one area where I’ve found Codex is a lot better than Claude. Sessions last forever without degrading. Codex doesn’t forget things that Claude drops from context.
Why don't people just simply use the combination of
it works perfectly well for me to continue where I left off for any project I'm working on.how do you update those files?
I always add instructions INSIDE of both `Readme.md` and `*-instructions.md` to "update this file if anything major changed".
Additionally, after implementing a feature, I tell it to summarize the major decisions in either / both of those files.
Very good problem solve. Claude for some reason doesn't have access to other sessions. But the way around it is doing a project, that giving project context.
This is good. Has anyone tried building any large scale applications entirely using Claude and maintaining it for a while with users paying for it? I’m looking for real life examples for inspiration.
Honestly memory seems like an overcomplicating way to solve this problem in the context of something like a coding agent. Rules and Skills are much more explicit, less noisy and easier to maintain. Just requires having an always on rule/system prompt to always update rules/skills as designs or architecture changes in a way that conflicts with old rules. Memories maybe make more sense for personal assistant use cases.
Kind of a silly question but what limits this to just Claude Code? Seems like it'd work with aider, OpenCode or even vibe.
I like the idea of various extensions of LLM context using transparent plaintext, automatic consolidation and summarization... but I just can't read this LLM-generated text documenting it. The style is so painful. If someone ends up finding this tooling useful I hope they write it up and I hear about it again!
I am in the same boat. Reading is a transaction and lately everyone wants to put 60 seconds of effort into writing an article and expect me to put 10 minutes into reading it, and I just can't. The writing feels dead, soulless even. Every sentence or phrase is structured like a mongering, click baity headline and it's insufferable.
My first thought was: yet another memory architecture for Claude. But the concept is quite cool. I’m not sure I’ll use it for Claude for I told my OpenClaw instance to copy the idea and setup a cronjob.
how do you evolve this? you have received a couple of suggestions to make it better. How do you evaluate whether a different strategy yields better results?
Didn't epstein fund the original COG AI project out of Hong Kong?