Monday morning. You open your editor, or terminal and fire up your AI coding assistant, and type something like "continue working on the payment service refactor." The response comes back asking what payment service you mean. Even worse is a confident response only to find out two hours later you need to start over because original scope was dropped and assumed by your agent.

Everything you established in planning: the architectural constraints, the Q/A requirements, the feedback loop you incorporated and that outlined an approach that will be more defensive, the edge cases you flagged as future work, unusable. You're not resuming a project. You're re-briefing a new contractor who has your codebase but none of its history.

This isn't a bug in your tool. It's a design choice. But it's a design choice that's becoming harder to justify as the work we ask these tools to do gets more complex. We've all felt it and its becoming harder and harder to accept.

The Amnesia Problem

Let's be specific about what gets lost, because "context" is too vague a word for the problem.

Between sessions, AI coding tools lose several distinct things:

• working knowledge: the decisions you made and why, the trade-offs you consciously accepted, the constraints imposed by other systems or teammates.
• Project semantics: what your abstractions actually mean in your specific codebase, not what they'd mean to someone reading the code cold.
• Change rationale: why the code looks the way it does, which is almost never visible from the code itself.
• Task continuity: where you were, what you were trying to accomplish, what you'd already ruled out.

The result is that every session starts from the same place: a model that can read your files but has no memory of working in them with you.

Why LLMs Are Stateless by Design

This is intentional, and when you understand why, you can't really argue with the original decision.

Large language models are trained on static datasets and deployed as inference engines. A request comes in, tokens go out. There's no persistent state between calls, no accumulating memory, no mechanism for one conversation to influence the next. Each call to the model is independent.

This architecture made complete sense when AI coding tools were sophisticated autocomplete. Autocomplete doesn't need memory. It needs a good model of code syntax and common patterns, applied to whatever is in the current file. Statelessness is actually an asset there: it keeps latency low, makes the system horizontally scalable, and prevents one user's context from contaminating another's.

The problem is that these tools have grown into something different. They're being used for multi-step reasoning tasks, architectural discussions, multi-session refactors. The usage pattern has evolved dramatically, but the underlying architecture hasn't kept up. There are approaches to provide working memory into agent sessions, but there is a very small horizon of quality until every session falls off a cliff.

The Workarounds Developers Use

Developers aren't passive about this. The workarounds are real, widespread, and instructive about what people actually need.

The most common is the context dump: pasting long summaries of prior work, architecture notes, or even entire conversation histories into the system prompt. Some teams maintain AGENTS.md files or similar documents specifically to brief AI tools at the start of each session. Others use memory features built into tools like Cursor or Claude, which persist selected information across conversations.

These approaches aren't wrong. For simple projects with small teams, they work adequately. The problem is that they don't scale.

Manually curated context documents get stale. Someone updates the architecture and forgets to update the doc. The model reads an outdated constraint and gives you advice that's technically correct but practically wrong for your current setup. Context windows fill up, forcing you to choose what to include and what to drop — and you're often making those choices without knowing what the model will actually need.

And none of these approaches capture the informal, high-value knowledge that never makes it into documentation: the "we tried that and it didn't work" moments, the decisions made in pull request comments, the reasoning behind the code that looked weird to the last reviewer.

What Memory Actually Means in a Coding Context

Here's where the word "memory" does real damage if used loosely.

When people talk about AI memory in a chat context, they typically mean something like persistent preference storage: remember that I prefer concise responses, remember that my name is Alex, remember that I work in Python. That's a solved problem, more or less, and it's not the hard part.

Code agent memory is structurally different. What you need isn't a log of prior conversations. You need a living model of a codebase that includes:

• How the project is structured and why
• What decisions have been made and what drove them
• How the code has changed over time and what motivated those changes
• Which parts of the codebase are stable and which are actively in flux

This isn't retrieval. It's comprehension that persists and updates. The distinction matters because a lot of current approaches treat this as a retrieval problem when it's actually a knowledge representation problem.

The Three Layers a Code Agent Needs

Break it down and there are three distinct types of knowledge a code agent needs to maintain across sessions.

Project structure knowledge is the static layer: what modules exist, how they relate to each other, what the public interfaces look like, what the data models are. This is the layer that's easiest to extract and index. Most code intelligence tools handle this reasonably well.

Decision knowledge is the layer that almost no current tool maintains. This is the record of choices: we use this pattern because the other one caused problems with X, this service is split this way because of the team ownership model, this interface is deliberately limited to prevent misuse in context Y. This knowledge lives in people's heads, in PR descriptions, in Slack threads, and in commit messages, scattered and undiscovered.

Change history is not the same as Git history, though Git is an input. It's a semantic understanding of how the codebase has evolved: what has changed recently and therefore might be inconsistent, what was just refactored and should be treated as stable, what is currently being actively modified and therefore risky to touch. An agent without this layer will confidently suggest changes that conflict with work in flight.

Why Retrieval Alone Falls Short

Retrieval-augmented generation (RAG) has become the standard answer to context window limitations. The idea is straightforward: index your codebase, retrieve the most relevant chunks at query time, stuff them into the prompt. It works well enough to be useful. Most recently CAG (Cache Augmented Generation) has made headlines and is a more optimized way to run, but only for certain scenarios. There is still a foundational retrieval problem.

The limitation is that relevance-based retrieval is optimized for answering questions about code that exists. It's poorly suited to answering questions about decisions, constraints, and history, because that knowledge isn't consistently present in the code itself, and when it is, it's not in a form that retrieval systems surface well.

Retrieval finds what's there. It doesn't reconstruct what was decided and why.

There's also the coherence problem. Retrieving chunks from across a large codebase and assembling them into a prompt produces a context window full of fragments with no organizing structure. The model has to do real work to reason about relationships between them, and it often gets it wrong. Curation is fundamentally different from retrieval: it requires understanding the project as a whole and selecting what's relevant based on that understanding, not just similarity scores.

What a Real Solution Requires

A genuine solution needs persistent, structured knowledge that exists outside the context window and gets maintained across sessions. Not a flat document, not a vector index, but something that models the project itself: its structure, its decisions, its history, and the relationships between all three.

That knowledge layer needs to update as the codebase changes. It needs to be queryable in ways that reflect how developers actually think about their projects. And it needs to surface the right context to the agent automatically, without requiring the developer to manually brief it at the start of every session.

This is the problem Cognisos is working on with Fabric: a code intelligence and memory layer delivered via MCP that gives AI coding agents persistent, structured knowledge of a project across sessions. **The approach is curation, not retrieval. **

Fabric is currently in development with phase one live for users. This features robust indexing and codebase relationship tools to power every session. It is entirely local first and each sign up comes with 250 free tool uses. Try it out through a simple install: npx -y @cognisos/fabric-mcp setup

Phase 2 will hold a cloud sync system and ability to share your personal knowledge store. An evolving memory layer that closes the gap between assumption and truth. If interested in beta testing, set up a time with us HERE.

Interested in learning more? Here's some related articles.