Ask HN: How do you handle long-term memory with AI tools like Cursor and Claude? | Hacker News Reader

Ask HN: How do you handle long-term memory with AI tools like Cursor and Claude?

3 pointsJakaKotnik2 comments

I keep running into the same friction point when coding with AI tools. They are amazing inside a single session, but the moment you open a new one, they forget everything about the project, past reasoning, edge cases, or architecture notes.

I know some people maintain MD files or detailed RAG setups, but most developers I talk to say their context is scattered across Slack, GitHub issues, Notion, docs, emails, etc.

So I’m curious how others solve this today:

• Do you rely on project-local markdown files? • Do you manually restitch context every session? • Have you built your own external memory store? • Or do you just accept that AI will forget most things between sessions?

Not trying to promote anything. I genuinely want to understand whether this is a real pain point across teams or just a “me” problem.

Would love to hear how you manage long-term context in your workflow.

Hit exactly this problem some time ago (preliminarily buried 5 or 6 versions of memory systems).

Generic summaries or RAG results often feel useless because models optimize for "what would be useful to explain to anyone" rather than "what was significant in this specific context."

What worked for me: separate semantic context (the "why are we here" layer) from structured tracking (decisions, blockers, dependencies). The semantic layer captures salience — what mattered emotionally or strategically — and the tracking layer handles facts or even snapshots of the latest state of the process.

The model does not have to guess what was important. The memory architecture can encode it.

In short, MD files. After stuff works, I canonize the documentation about how it works by having Cursor write all of that in a special folder. Then, I can @reference that folder or a doc in it at the start of a prompt that will need that context.

It's part of a larger process for working with LLMs that I call "Plans on Plans." I wrote about it on Medium.[0]

[0] https://levelup.gitconnected.com/you-are-bugs-improving-your...

Reply on news.ycombinator.com