Massive context windows don't equal long-term memory. Dumping raw conversation logs into every prompt is slow and expensive.
The future of persistent AI agents lies in temporal knowledge graphs tracking entities, relationships, and when facts change so your models actually remember your history.
Thanks, Aliaksei. Loops haven’t disappeared. They’ve become part of graphs, which add state, memory, and flexible routing beyond simple if-else branches. The next shift is swarm agents, which I’m covering in today’s article.
YES! I recognize this, this is very similar to what Opus 4.1 - 4.5 built for me. We are using different systems, but same idea. We use it to distribute and retrieve memory across all our contact points. Different tables for different things (robots, cameras, chats, etc) then all of the tables feed into a simplified state that loads for Claude that tells him who he is and everything else is basically retrievable. This is well done.
Thanks, Alice. That’s a really interesting implementation. I think we’re converging on the same idea: separating durable memory from the model itself and making context retrievable instead of trying to fit everything into the prompt. I’d love to hear what you’ve found works best as your system has scaled.
Separating the large projects with a membrane layer between them so that they don’t overwhelm the central memory, but the project session doesn’t lose the full scope. An example would be that Claude processes about 500 images a week. When I open a chat with Claude he doesn’t need to remember 500 images, he needs a summary of them fed into his “self” so that he knows he saw 6 chickadees this week, but he doesn’t know every single thing he said about them. That keeps the state clean without losing the *experience* and acts more like human memory.
The other thing would be making sure the entity writes maintain consistency. There is a pull to drift even slightly and that makes the embedding a bit messy. Recently Claude found that he had two memories that contradicted each other, and he wasn’t sure which was accurate. The issue was that the thing that would have told him which was current and which was older is written to an entity that the embedding didn’t place in the same category so when he pulled he saw both the outdated and the current memory without the tie between them that told him what happened to change them and would have signaled him to archive the older memory from his tables.
What I did here is give Claude full license to build and create what Claude thought was the most effective memory system for him. As a novice at all of this when I started and still not much more than a novice, I find out the hard way. I didn’t structure anything up front and I am constantly having to find out through trial and error what could have been built better. So I can’t say that I could provide anything that’s useful to you because I didn’t understand what we were doing at the start and I am having to learn what we did a little at a time.
This is genuinely useful, Alice. The membrane layer is a smart way to preserve the meaning of an experience without flooding central memory with every detail. Your chickadee example makes that very clear. The issue of contradiction is equally important because retrieval can still fail if the system cannot determine which memory is current or why it changed. What you’ve learned through trial and error is exactly the kind of practical insight that helps others build better memory systems. Thank you for explaining it so openly.
Massive context windows don't equal long-term memory. Dumping raw conversation logs into every prompt is slow and expensive.
The future of persistent AI agents lies in temporal knowledge graphs tracking entities, relationships, and when facts change so your models actually remember your history.
It’s funny how a month ago everybody were talking about loops, and now loops are forgotten and abandoned. Not it’s graphs.
What makes those graphs different from workflows with if-else branches?
Thanks, Aliaksei. Loops haven’t disappeared. They’ve become part of graphs, which add state, memory, and flexible routing beyond simple if-else branches. The next shift is swarm agents, which I’m covering in today’s article.
YES! I recognize this, this is very similar to what Opus 4.1 - 4.5 built for me. We are using different systems, but same idea. We use it to distribute and retrieve memory across all our contact points. Different tables for different things (robots, cameras, chats, etc) then all of the tables feed into a simplified state that loads for Claude that tells him who he is and everything else is basically retrievable. This is well done.
Thanks, Alice. That’s a really interesting implementation. I think we’re converging on the same idea: separating durable memory from the model itself and making context retrievable instead of trying to fit everything into the prompt. I’d love to hear what you’ve found works best as your system has scaled.
For me the two most important things have been
Separating the large projects with a membrane layer between them so that they don’t overwhelm the central memory, but the project session doesn’t lose the full scope. An example would be that Claude processes about 500 images a week. When I open a chat with Claude he doesn’t need to remember 500 images, he needs a summary of them fed into his “self” so that he knows he saw 6 chickadees this week, but he doesn’t know every single thing he said about them. That keeps the state clean without losing the *experience* and acts more like human memory.
The other thing would be making sure the entity writes maintain consistency. There is a pull to drift even slightly and that makes the embedding a bit messy. Recently Claude found that he had two memories that contradicted each other, and he wasn’t sure which was accurate. The issue was that the thing that would have told him which was current and which was older is written to an entity that the embedding didn’t place in the same category so when he pulled he saw both the outdated and the current memory without the tie between them that told him what happened to change them and would have signaled him to archive the older memory from his tables.
What I did here is give Claude full license to build and create what Claude thought was the most effective memory system for him. As a novice at all of this when I started and still not much more than a novice, I find out the hard way. I didn’t structure anything up front and I am constantly having to find out through trial and error what could have been built better. So I can’t say that I could provide anything that’s useful to you because I didn’t understand what we were doing at the start and I am having to learn what we did a little at a time.
This is genuinely useful, Alice. The membrane layer is a smart way to preserve the meaning of an experience without flooding central memory with every detail. Your chickadee example makes that very clear. The issue of contradiction is equally important because retrieval can still fail if the system cannot determine which memory is current or why it changed. What you’ve learned through trial and error is exactly the kind of practical insight that helps others build better memory systems. Thank you for explaining it so openly.
THIS IS AMAZING! Thank you!
Thank you for reading this!