I think AI development is slowing, though I say that from a position where I use models newer and better than Opus 4.6 rarely or not all due to cost. I think the issue is that memory systems are reaching a point where they provide diminishing returns. I think the problem is one of awareness/consciousness, not just memory. It only helps the agents so much to have data stored in a memory system, whether .md files or a database, because the memory is not an active system maintaining persistent awareness/consciousness. You can automate optimization and even some recall from the data stored, but that just isn’t the same thing as human awareness. It is very limited. My memory-journal-mcp system prunes, optimizes, verifies, gives significance and trust scores, etc., but much of the data still just remains stuck and rarely used. Perhaps you could create a set of keywords that when used in session/thread trigger the agent to search but even that is still sort of one dimensional and I think would be inconsistent. Of course, some of the problem is that agents often simply don’t need memories in order to solve a particular problem. Perhaps an explanation for a recent architectural decision might inform their coding and even speed up finding a solution to a resulting problem slightly but, in many cases, the agents can fix things without such memories. This means the user/developer has no real idea when a memory lookup is really useful and when it is just overhead.
Hey interesting take, especially the part about diminishing returns in memory systems. I agree with the key point: storage whether it’s .md, a DB, or an MCP like your memory-journal is a passive layer, not persistent awareness. The model doesn’t “hold” context between sessions, it rebuilds it each time from whatever you feed into the context window.
I think the issue of “when lookup is actually useful” is basically a retrieval relevance problem, not memory itself. Keyword triggers, like you mentioned, give a one-dimensional and unstable result. A more practical direction is to tie recall to the task or files the agent is working on right now like architectural decisions linked to specific modules, not a global store so memory only comes up when there’s real semantic overlap with the current change. That reduces the overhead you’re talking about.
This is being discussed in a couple other threads too if you want to dig deeper:
- How are people handling context across different AI coding tools?
- Is anyone else tired of re-explaining who you are every time you switch between GPT, Claude, Cursor, etc.?
I’d be curious to hear how you handle significance and trust scores in memory-journal-mcp. Scoring feels like the place where you can claw back most of that overhead.
The significance and trust scores mitigate the problem a little but don’t eliminate it. It still has to be a “conscious” decision to access memory rather than an “organic” process. memory-journal-mcp is very useful but I haven’t released a new version in a long while because I have been trying to work on these problems. But, at this point, I am stuck. So, I may release it. Ironically, the biggest advantage of it now is how it intercepts terminal commands to heal them and make them work. I have reduced terminal failures by about 35% though it seems to be hitting diminishing returns now and of course the numbers vary depending on the type of work/terminal commands. This is a separate thing from memory but still fit in memory journal pretty well.