I used to keep AI chat sessions open far longer than made sense, because closing one meant re-explaining my project from scratch. Rahul Garg has a name for the fix: context anchoring, "the practice of making that alignment durable." It went up on martinfowler.com and it is worth your ten minutes.
His test for whether you have got it right is the part that stuck with me:
If I can close my chat session and start a new one without anxiety, my context is properly anchored. That reframed the problem for me. I had been treating the long session as the asset. It is the symptom.
Once you accept that context should live outside the conversation, you have to decide where. There is a whole category of hosted "AI memory" products that will answer this for you, and I went and benchmarked one properly this week before deciding.
I would rather anchor to markdown files in the repo:
Sync is a fine optional layer. It should not be the substrate.
I measured both approaches on the same machine.
| Tokens per request | |
|---|---|
| File-based memory: a one-line index, 15 entries | 579 |
| Hosted memory MCP: 27 tool schemas, 0 entries stored | 8,866 |
The hosted service costs roughly 15x more per request, before it has remembered anything at all. The reason is architectural. MCP tool definitions ship on every single request whether you call them or not, so a broad tool surface is a permanent tax. A file-based index loads one line per memory and fetches the body only when it looks relevant.
Same idea. An order of magnitude apart in cost, purely from where you put the state.
Garg scopes his advice carefully, and the article is about capturing decisions while they are fresh. Here is what I hit after doing this for a while.
Yesterday I wrote a memory saying an automated check "does not exist yet and is worth building." Today I built it. The memory was now confidently, specifically wrong, and nothing flagged it. It would have kept telling future sessions to build a thing that already existed.
Anchored context decays exactly like documentation, except an AI reads it with more trust than a human would and acts on it. A decision record that names a function deleted last month gets asserted, not questioned.
So my working rule: every anchor carries the date and the reason, and anything naming a file, function or flag gets verified against the repo before I act on it. Writing the anchor is the easy half. Keeping it honest is the actual work, and I have not seen anyone solve it properly yet.
If you are already doing this, I would like to know how you handle staleness. That is the open problem.