The Groundhog Day Problem

Every morning I re-introduce myself to my tools. Not literally, but close enough. I open a fresh session and the assistant has no idea what I was doing yesterday, what we decided, what we tried that didn’t work, or why the project is shaped the way it is. We worked all of that out already. It just wasn’t there anymore.

The standard advice is to treat this as a prompting problem. Write a better opening prompt. Paste in more background. Keep a little block of context you drop at the top of every session so the thing knows who you are and what you’re up to. So you get good at prompting, and you build the ritual, and it helps, a bit.

But you’re papering over the actual problem, which is that the system has no state. A prompt isn’t memory. It’s you, by hand, reloading yesterday into a thing that forgot it. Every session starts at zero because nothing was ever written down in a place the next session reads from.

This is a state failure, not a prompting failure, and the difference matters because the fixes are nothing alike. If it’s a prompting problem, the answer is “try harder at the start of every conversation, forever.” If it’s a state problem, the answer is to give the system somewhere durable to keep what it learns (decisions, project structure, the things that didn’t work) so the next session can read them instead of asking you again.

We solved this for software a long time ago. A server that forgot everything every time it restarted wouldn’t be called badly configured, it would be called broken, and we’d put a database behind it without thinking twice. A lot of people are running their AI workflow like that server with no database, and calling the daily re-explanation a prompting skill.

I’m not going to pretend the storage layer is a solved, buy-it-off-the-shelf thing yet. (It mostly isn’t, which is its own post.) But the first move is to stop calling it the wrong problem. You don’t need a better prompt. You need somewhere for yesterday to live.