I am testing a different way to give AI memory, decisions instead of chat history
Most tools store your chat history and search it later. I tried this and it never really worked for me, the model finds an old message but it still does not know what I actually decided.
So I am testing something else. The thing I store is a decision, not a message. Each one has the decision itself, the reason behind it, the date, and a status.
Around it I keep 3 more files, one for the stable facts about me and the business, one for what I am working on right now, and one file per topic so nothing gets lost in the middle.
The part that surprised me is not the recall. It is that when I say something that goes against a decision I made before, it stops me, shows me the old one with the reason, and asks me what changed. It caught me twice this month.
It is all just markdown files right now and very manual, I am testing the behaviour first before I build anything real.
I am still not sure about 2 things. If people actually want to be confronted with their own old decisions, and how much should happen automatically vs asking me to confirm every time.
Would love to hear what you think, especially if you tried something like this and it did not work.
Replies
Storing the decision plus the reason feels much more useful than replaying old chats. The “what changed?” interruption is especially valuable because it turns memory into a consistency check, not just recall.
I’d probably only trigger it when the old decision is both active and clearly relevant, otherwise it could get noisy fast. How are you thinking about deciding that relevance threshold?
@alpertayfurr Honestly this is the part I have not solved yet. Right now it is not semantic search, every decision is attached to a topic, so when I start talking about pricing it only pulls the pricing decisions and ignores the rest. That kills most of the noise but not all of it. The other thing that helps is that nothing enters the ledger unless I confirm it, so the file stays small and everything inside it is actually real. But your version is stricter than mine, active AND clearly relevant. how would you decide active? by a date, or by me saying the phase is over?
@momen_elshamy I’d make “active” state-based rather than date-based. A decision stays active until you explicitly close that phase or a newer decision supersedes it. Dates can help as a warning signal, but I wouldn’t let time alone expire something that may still be valid.
Creating files for each context is good for smaller repos but as your app grows this will expand exponentially making the file bigger and it starts eating up most of the context and a leaves a little for the actual work to be done.
My suggestion would be a hybrid approach between tool and instructions files with dynamic and static info respectively.
For example, the strategy, legal, compliance, tech stack, standards, rules can be static skills and instructions and the decisions made for case by case basis can be in the tool such as mem0.