Re:The Components of Agent Memory
by bbor on Saturday November 07, 2026 @07:40AM
(#50404057)
So the main improvement to memories I'd like to see is better judgment on which ones to create.
Well you have good instincts, then! It's probably not obvious on the first read-through, but Figure 4 shows the qualitative strides they've made on this goal.
I started with [proactive post-hoc analysis], and ended up following some threads to interesting insights.
Can definitely echo that experience, glad I'm not alone. I think this actually speaks to your initial complaint/observation in an allegorical way, though: Anthropic designs the [memory/tendency-to-reflect] systems to cover a huge breadth of usecases and preferences, and they help a lot compared to [statelessness/never reflecting] but are distractingly inferior to alternatives that the user takes an active part in shaping and using.
I also finally pulled the trigger on deprecating the last ClaudeCode memories on my system recently in favor of a personal system[1], and the issues I noticed informed that take by being things a casual vibe coder might appreciate, but any engineer working fulltime on multiple projects via multiple harnesses would find counterintuitive. E.g.:
- The memories were hidden away and clearly not written for human eyes; useful for low-stakes ledgers, frustrating when the right kind of errant note can derail a longrun 2 weeks later.
- The memories seemed to err towards the side of remembering everything and recording incidental details; useful for remembering the user is gluten-free, but not for tracking spec changes over time.
- The memories could be specific to a subagent or the a project or the whole system; ...this one just kinda seems like a logical first idea that falls apart in practice for everyone.
[1]: if curious, a somewhat-outdated version of it is here: https://gitlab.com/doering-ai/libs/fleet TL;DR: Friendship ended with ClaudeCode memory files; my new best friends are `BULLETIN.md` for transitory alerts, `campaigns/[slug]/LEDGER.md` for basic episodic memory, and `reports/[date]-[slug].md` for writeups polished specifically for posterity.
I also finally pulled the trigger on deprecating the last ClaudeCode memories on my system recently in favor of a personal system[1], and the issues I noticed informed that take by being things a casual vibe coder might appreciate, but any engineer working fulltime on multiple projects via multiple harnesses would find counterintuitive. E.g.:
- The memories were hidden away and clearly not written for human eyes; useful for low-stakes ledgers, frustrating when the right kind of errant note can derail a longrun 2 weeks later.
- The memories seemed to err towards the side of remembering everything and recording incidental details; useful for remembering the user is gluten-free, but not for tracking spec changes over time.
- The memories could be specific to a subagent or the a project or the whole system; ...this one just kinda seems like a logical first idea that falls apart in practice for everyone.
[1]: if curious, a somewhat-outdated version of it is here: https://gitlab.com/doering-ai/libs/fleet TL;DR: Friendship ended with ClaudeCode memory files; my new best friends are `BULLETIN.md` for transitory alerts, `campaigns/[slug]/LEDGER.md` for basic episodic memory, and `reports/[date]-[slug].md` for writeups polished specifically for posterity.