What your AI forgets between sessions

You spent last Tuesday afternoon figuring out why the webhook retry logic was causing duplicate events. You settled on an idempotency key approach, ruled out a queue-based alternative because of the existing Redis footprint, and wrote it. The code is in. It works.

On Wednesday morning you open a new Claude Code session and ask a question about the payment flow. The answer recommends a queue-based approach for exactly the problem you just solved. Claude does not know what you decided. Claude does not know why you ruled out the queue. You are the only one who remembers, and you are going to have to explain it again.

This is the session boundary problem. Every AI coding tool has it. It is not a bug; it is an architectural reality. The context window closes, the session ends, the slate is clean. The model knows everything about code in general and nothing about your project in particular, starting from zero each time.

What actually gets lost

Most people think of this as a "memory" problem and reach for tools that store summaries. Project descriptions. README files. CLAUDE.md files with instructions at the top. These help. They are not the problem.

The problem is the decisions that never get written down.

The webhook retry approach was a decision. The ruling-out of the queue alternative was a decision. The five minute conversation you had with a teammate that resolved why the staging environment behaves differently than production; that was a decision. The constraint your PM mentioned last Thursday that makes a particular approach unworkable; that is a decision. None of these go into the codebase. None of them go into a README. You carry them.

When the AI has a fresh context window, it has access to everything you have written and nothing you have concluded. The gap compounds over time. By week four of a project, the ratio of what the AI knows to what it does not know about your specific situation has gotten worse, not better.

The approaches that do not work

The instinct is to write things down. A decisions log. A constraints document. A "what we tried and why it failed" file. This works if you maintain it. Most people do not, because the discipline required to update a document after every significant technical decision is the same discipline that would be required to write excellent commit messages on every commit. It is correct in theory and rare in practice.

Claude Projects and Claude Memory address a real problem with a partial answer: they remember across sessions with the same tool. If you use Claude exclusively, the cross-session context works. The moment you open a different tool, the context is gone again. A Cursor session does not inherit your Claude Project. A Windsurf session does not know what you told Gemini last week.

The AI tool you use tomorrow does not exist yet. It will be released sometime in the next 12 months and it will be meaningfully better than whatever you are using today. When you switch to it, your context stays behind.

What a cross-session context layer does differently

The approach Mandaire takes is structural rather than discipline-based. Instead of asking you to maintain a decisions document, it builds a graph of what you know from the sources that already capture it: your messages, your conversations, your email threads, your calendar. When you discuss a technical constraint with a collaborator over iMessage, that conversation goes into the graph. When you receive an email from a vendor explaining a rate limit you need to design around, that constraint is captured.

The graph is not a transcript. It is a knowledge layer: entities, relationships, and inferences extracted from the raw signal. When you connect an AI coding tool to Mandaire via MCP, it can query this layer before responding. It does not need you to paste context at the top of every session.

The AI does not need to know about idempotency keys in general. It already knows about them. What it was missing was the project-specific context: that you chose that path, that you had a reason to rule out the alternative, that the decision was made and closed. That context now exists in the session before you ask the first question.

What this looks like in practice

The most useful framing is not "AI memory." It is "who knows what." In a small team or solo project, the human is the only one who knows the project-specific decisions, constraints, and dead ends. The AI tools know everything else. The knowledge is siloed in the human, which means every session starts with a translation step: the human re-explains what the AI should already know in order to get to the actual question.

Mandaire removes that translation step. The knowledge is in the layer; the AI reads it. You start with the actual question.

The other useful framing: your AI coding tool is going to be replaced by a better one. The new one will not inherit your context. If your context is in a document file, you paste it again. If your context is in a knowledge graph with an MCP endpoint, the new tool reads it on day one. The switching cost is zero. The accumulated knowledge transfers.

Who this is for right now

Mandaire is self-hosted. You run it on a machine you control, your data stays local, you connect it to Claude Code or Cursor or any other MCP-compatible tool. There is no cloud account to create, no data sent to a third party, no subscription entangling your knowledge graph with a vendor's survival.

The setup takes about 20 minutes if you are comfortable with Docker and have a Claude API key or Claude Max subscription. The install guide is at mandaire.com/install. The technical documentation for the MCP interface is at mandaire.dev.

If you are using Claude Code seriously and have been frustrated by the session boundary problem, this is the direct solution to it. The knowledge graph fills in the gap that Claude Projects leaves: cross-tool, cross-session, running locally, owned by you.