Why AI Coding Assistants Forget Everything (And How We Fixed It)

Here is a question nobody asks when they first start using an AI coding assistant: where does everything go when I close the terminal? The answer is nowhere. It vanishes. Every decision you explained, every convention you corrected, every bug workaround you described -- gone. The next session starts with a blank slate.

This is not a bug. It is a fundamental architectural constraint. Understanding why AI coding assistants are stateless by default explains why bolting on memory is harder than it sounds -- and why most approaches to persistent AI context fail.

The Stateless Architecture Problem

Large language models do not remember. They predict the next token based on what is in the current context window. When Claude Code, Copilot, or Cursor processes your code, it sees only what is in the active conversation: the files you have open, the messages you have sent, and the system prompt. There is no persistent state layer. No database tracking what you said yesterday. No knowledge graph connecting your decisions across sessions.

This is by design. Statelessness makes LLMs scalable, privacy-safe, and predictable. But it creates a brutal user experience for developers who use AI assistants as long-term collaborators rather than one-shot question-answerers.

The Three Approaches That Do Not Work

1. Stuffing the System Prompt

The most common workaround is a giant CLAUDE.md or .cursorrules file that describes your entire project. This works for static conventions but breaks down for dynamic context -- decisions made during sessions, bugs discovered this week, threads being actively investigated. You end up manually maintaining a knowledge document that is always out of date.

2. Saving Entire Conversations

Some tools try to persist full conversation histories and replay them. This hits the context window limit fast. A typical Claude Code session generates 50,000 to 200,000 tokens. Injecting even a fraction of that into the next session blows your context budget on stale conversation fragments instead of relevant project knowledge.

3. Unfiltered Memory Capture

The naive approach: save every piece of context the AI encounters. Within a week this produces hundreds of memories, most of them noise -- 'user asked me to fix the bug,' 'I have completed the task,' 'the code looks good.' The signal-to-noise ratio collapses and the AI spends its context budget on useless meta-commentary instead of actual project knowledge.

What Persistent AI Memory Actually Requires

After building and testing four different approaches over six months, we arrived at the architecture that became Cortex. The problem is not storage -- SQLite handles that trivially. The problem is curation. A useful memory system needs five things.

The Result: Cortex

Cortex implements all five requirements as an open-source MCP server for Claude Code. Six memory types with distinct lifecycles. A 7-rule quality gate. Token-budget-aware context injection with importance scoring. Automatic project detection. SQLite on your machine with optional Turso sync.

The gap between a stateless AI assistant and one with persistent memory is the gap between a contractor you have to re-onboard every morning and a team member who has been on the project for months. If you want to close that gap, Cortex takes two minutes to install and the first session will show the difference.