The story
I was building a website for a client who sells courses. The structure of the data was specific — some courses had one instructor, some had several, some instructors taught one course, some taught many. I was trying to find a way for visitors to search and navigate all of this easily.
The problem was that every time I sat down to work on it, I had to explain the whole thing again from scratch. The relationships between courses and instructors. The edge cases. The constraints. By the time I had explained enough for the answers to be useful, I had lost twenty minutes and a fair amount of patience.
What I eventually understood was this: these tools don’t carry memory from one session to the next. That is not a flaw — it is simply how they are built. Whatever I had explained the day before was gone. I was not dealing with a colleague who remembered the project.
The solution, when I found it, was not what I expected. I asked the AI to interview me — what does it need to know to give me genuinely useful answers? It asked the questions. I answered them. It wrote the document. From that point on, I loaded that document at the start of each session and could begin working immediately.
The tool hadn’t changed. What had changed was that I had stopped expecting it to remember, and started keeping my own record.
What that led to was something larger. If one project needed its own document, so did every project. And if I was going to maintain those documents properly — keeping them accurate as projects evolved — I needed somewhere to keep them that was independent of any AI tool entirely. That is what eventually led me to building a proper knowledge base: a structured, persistent record of project information that I own and control, and that any tool can draw on at the start of a session.
The point
[to develop — AI tools have no persistent memory by design. The answer is not a better prompt. It is your own record, kept independently, that you bring to each session.]
