What does your AI assistant remember from yesterday?

A developer found that AI assistants lose context between sessions, costing nearly three hours a week in re-explaining setup details. The developer proposes a simple memory loop—writing one-line lessons at the end of sessions and pasting them at the start—and warns that delivery, not storage, is the critical failure point.

Context that survives Answer it without opening a chat window. What does your assistant know this morning that it learned yesterday? For most setups the honest answer is nothing, and nothing has a price. But that is the easy version of the problem. The one that actually cost me an afternoon is worse: it knew, and it did not tell me. The fact was stored, it was displayed, and I made the mistake anyway. More on that below, because it is the part everybody gets wrong on the first try — and the part nobody warns you about. Take one week and count the first messages of your sessions. Not all messages, just the opening one of each. In my own week, seventeen of twenty-two opening messages were setup. Which servers exist, which one runs the database, which deploy path is the real one, which trap I fell into last month. Roughly ten minutes each before any work started. That is nearly three hours a week spent re-teaching facts that had not changed. Not learning anything. Re-typing. Before you take that number anywhere: it is one person, one week, twenty-two sessions. It is not a study and I would not defend it as one. The reason I am handing it to you is that it took twenty minutes to produce, and you can produce your own by tomorrow morning. That is the only part of it I would argue for. The worse half is invisible: the sessions where I did not bother re-explaining, and the assistant confidently used the wrong server name because nobody had told it otherwise. A bigger window makes one conversation smarter. It does nothing across conversations, and across conversations is where the work actually lives. The knowledge you need tomorrow was produced today, at the end of a debugging session, in the moment somebody said out loud why the thing broke. That sentence is the asset. It exists for about thirty seconds and then the window closes. Documentation is supposed to catch it and mostly does not, because writing docs is a separate task with separate motivation, performed at the exact moment you least want another task. So the sentence needs to be captured by the participant who is already typing: the assistant. Two things get better, and one gets uncomfortable. Better: the first ten minutes disappear. The assistant reads what it wrote before, and starts from the state of the world instead of from zero. You notice this as the absence of an annoyance, which is a strange kind of win to measure but a real one. Also better: repeated mistakes get expensive to repeat. When the reason a thing broke is written down where the next session reads it, the second occurrence of that mistake stops being free. Uncomfortable: you find out how many of your problems were repeats. In my own recorded set, several entries described mistakes I had already made twice. The memory did not make me smarter. It made me stop paying twice. Storing is easy. Delivering is where this fails, and it fails quietly. I had a lesson stored that contained the exact address I needed, along with a warning against the exact mistake I was about to make. It was displayed to me at the start of the session. I made the mistake anyway. The preview showed the first hundred characters. The address sat at character three hundred and twenty-three. The warning lived in a field that was never rendered at all. The store was perfect. The delivery was a sieve with a hundred-character mesh. If you build this, spend your effort on what gets shown, not on what gets saved. You can test the idea in an afternoon without adopting anything. Two habits and a file. First, at the end of any session where something broke and got fixed, write one line: what broke, what fixed it, which file. One line, not a document. Second, at the start of the next session, paste the lines that match what you are about to do. That is the whole loop, performed by hand. Third, and this is the part that decides whether it works: put the runnable thing first in the line. Not the backstory, the command. A file and two shell functions are enough to try it: mem=~/.memory.tsv save: one line, the fact FIRST, prose after remember { printf '%s\t%s\n' "$1" "$2" "$mem" remember "staging-db" "port 5433, NOT 5432 - 5432 is prod" } recall: grep, then read the whole line — not the first 100 chars recall { grep -i -- "$1" "$mem" | cut -f2 } Try it for a week. If recall returns something you would otherwise have retyped, you have your answer. If it returns nothing, you learned that cheaply. Two rules make the difference between this working and this rotting. Write the decisive fact in the first ten words. And when you truncate for display, truncate the prose, never the identifiers. Before: every morning you type the same three paragraphs about your own infrastructure, and on the mornings you skip it, you get confident answers built on the wrong assumptions. After: the assistant opens with what it learned last time, including the mistake it made and how that got fixed. Your first message is about today's work, not about your server names. A memory that stores everything and shows a hundred characters is not a memory. It is a filing cabinet nobody can open. I build cachly — persistent memory for AI coding assistants, over MCP. ChatGPT and Claude remember your conversations. cachly remembers your codebase: the bug you fixed, why you chose Postgres, the deploy step that always breaks — including what your teammates learned. And every assistant you use reads the same memory. Free tier, hosted in the EU: cachly.dev https://cachly.dev?utm source=devto&utm medium=article&utm content=what-does-your-assistant-remember