I’ve been writing; actually that’s a lie, Claude has been writing a lot of my code recently. Especially on some of the products I’m working on at my new, but not new, thing Heem Team. But one of things I keep bumping into is memory. Claude can remember things but the default is they live on a per machine basis.
Now this could be me not fully understanding the tool, and I’m quite certain that’s probable, but I think there’s a gap.
The gap
Rarely, if ever, is a project authored by one person AND exists on one machine. Yes, I work principally alone in the sense of humans (many agents, one human) but I work on multiple machines. A desktop, a laptop and modest cluster of Raspberry PI’s that form my homelab.
As a default Claude stores memory in this format $HOME/.claude/projects/hyphenated-path/memory and it’s markdown all the way down.
memory ls -al
total 64
drwxr-xr-x@ 10 jc staff 320 23 Jul 08:41 .
drwxr-xr-x@ 15 jc staff 480 23 Jul 08:14 ..
-rw-r--r--@ 1 jc staff 2652 23 Jul 08:41 dsr-billing-plan.md
-rw-r--r--@ 1 jc staff 3250 17 Jul 11:15 dsr-deploy.md
-rw-r--r--@ 1 jc staff 1225 19 Jul 11:46 dsr-live-run.md
-rw-r--r--@ 1 jc staff 1121 22 Jul 09:24 dsr-overview.md
-rw-r--r--@ 1 jc staff 1487 22 Jul 10:21 dsr-version-check.md
-rw-r--r--@ 1 jc staff 945 19 Jul 11:46 fj-cli.md
-rw-r--r--@ 1 jc staff 2847 17 Jul 11:02 forgejo-merge-signing.md
-rw-r--r--@ 1 jc staff 1263 23 Jul 08:41 MEMORY.md
The problem is that these memories live in each project on each machine. Now you can get around certain things that should not be memories with user level rules the ~/.claude/rules/*.md for high level preferences. That’s great because it applies to all projects, but, it lives on one machine. You can get hacky and have that be version controlled and symlink it and all manner of other shenanigans, but it kind of defeats the point of having agents do work as I’d be managing the memory.
A session with Claude on this topic gave a few outcomes to solve this, but there were all focused around a memory file transported via some protocol or tool (git, rclone etc) and symlinking. I’m just not into symlinking as a step to setting something up by hand. It seems distribution is the problem.
Magic wand
If I could wave a magic wand, I’d have that memory distribute itself so that it’s available to all my claude sessions and ideally, rather than using the directory name as the identifier to use a certain set of memories, I’d all it to be configurable so that I could manage that id and more importantly which memories are global, project and module specific. In that world I’d have the same memories organised in the same way.
The thing about working with an LLM is that your instructions have to be clear, precise and succinct. Just like “price, quality and speed” for me it’s always a choice of two, but never three. When there’s ambiguity it’s a problem because it forms part of the context, which gradually causes a kind of “cognitive decay” between you and the LLM. Eventually it surfaces as something that needs fixing, and when you challenge the LLM it comes back with “you’re right to challenge that and here’s why… I’ve updated my memory to reflect this”. Over time the differences between two machines become large enough to start conflicting with each other. You do some work on one machine, then you move to another machine and realises there’s some technical approach that conflicts and it changes it. Then you do some work on one machine, etc etc.
What I want is something like Linear (or any project management tool) that I have the LLM store it’s memories in. Configuring it via a skill.
Distribution
Like I said at the top of this post I’m thinking about this stuff as I’d like to fix it. But before I set to work I need to make sure I understand what entirety of the defaults. I don’t want to go solving a problem that is already solved, or worst of all coming up with a solution for a problem that only exists inside the perimeter of my own lack of knowledge.
But I think the gap is distribution. However, I could be wrong.
Time will tell.