Giving a Discord bot long-term memory, and the two ways it went wrong
I run a Discord bot called Akiko. The feature I care about most is that she remembers people across servers and DMs. Building it taught me more about what not to store than what to store. Two bugs stand out. Th
I run a Discord bot called Akiko. The feature I care about most is that she remembers people across servers and DMs. Building it taught me more about what not to store than what to store. Two bugs stand out.
The memory was 97% junk
My first extractor pulled "facts" out of chat with a loose pronoun pattern. It looked fine in testing. In production, when I finally read the table, almost all of it was noise: fragments that matched the pattern but described nothing about the person.
The fix had three parts:
- Clean the existing rows down to the ones worth keeping (about 100 survived).
- Make the writer classify a candidate before it saves it, instead of saving everything that matched.
- Treat "not yet judged" as its own state (NULL) and retry the judgment on an hourly job, so a temporary failure never turns into a permanent bad row.
The lesson: a memory system that only ever adds will bury itself. The write path needs a filter as strict as the read path.
She remembered what people had not said
The extractor also started storing absence as a fact, things like "User has not shared their birthday". That is worse than noise, because recall then surfaces it and the bot sounds like it is keeping a file on what you withheld.
I first tried marking these rows as low priority, but recall never filtered on that flag, so it changed nothing. The real fix was an extractor rule that refuses negative statements, plus a recall-side filter as a second line of defense.
Making it something users can control
Memory is only comfortable if the user can see and change it. Akiko has commands to list, add, delete and export what she has stored. There is also an import that takes a memory export from another AI and condenses it into clean facts, so a new user does not start from zero.
What I would tell anyone building this
- Read your memory table in production early. It will not look like your tests.
- Filter on the way in, not only on the way out.
- Never store the absence of information.
- Give users list, delete and export from day one.
Akiko is free to add: https://i.hep.gg/akiko
Dashboard: https://akiko.motzumoto.com
Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.