Every AI coding session starts from scratch. Claude does not remember that last week you decided JWT validation should use RS256. Cursor does not remember that you established a naming convention for the repository layer. Claude Code does not remember that the background job queue is FIFO only, with no priority support.
This is not a bug. It is the fundamental architecture of current language models: no persistent state between sessions. Context is built anew each time from whatever you put in the prompt.
The cost of this architecture is real and largely unquantified. Re-explaining context at the start of each session takes 5, 15 minutes depending on project complexity. Decisions made in one session get contradicted in another. Constraints established weeks ago get violated because nobody remembered to mention them.
This is the session amnesia problem. The Memory Tree is the fix.
The real cost of re-explanation
Teams that measure this consistently find the same pattern: 20, 30% of AI session time is spent on context re-establishment. The first message of many sessions is some form of "here's what we're building and the decisions we've made." The AI confirms it understands, and the actual work begins.
This re-establishment cost is not linear, it grows with project complexity. A week-old project might need 2 minutes of context. A six-month project with a dozen significant architectural decisions and a dozen team conventions might need 15 minutes, and even then, the re-explanation is incomplete. Some constraint gets forgotten. The AI violates it. You notice in code review.
What gets lost in re-explanation
The costs of imperfect re-explanation:
- Violated constraints: "never call the database from the API layer" is established in session 3, not mentioned in session 7, violated in session 8.
- Contradicted decisions: "use UUID v4 for all primary keys" in the data model created in session 2; "let me auto-increment the user ID" in session 9, because nobody mentioned it.
- Rediscovered context: the AI figures out a pattern that was established weeks ago, uses a slightly different approach, and you now have two conventions for the same problem.
Each of these is recoverable. But recovery takes time and introduces inconsistency. Over a project's lifetime, the accumulated cost of session amnesia is significant, more significant than most teams attribute to it, because each individual instance feels like a small correction.
What the Memory Tree stores
The Memory Tree is a structured collection of project facts: decisions made, constraints established, patterns adopted, preferences recorded. Each memory is anchored to a scope: a specific file, a module, a directory, or a cross-cutting concern.
When a new AI session begins, the Memory Tree is queried for the memories relevant to the files being worked on. The result is a scoped brief, a structured context that gives the AI the institutional knowledge it needs for this session without the overhead of a full project re-narration.
The session re-establishment cost goes from "15 minutes of prompting" to "the memory recall tool call", a few hundred tokens and a fraction of a second.
The write side: ratified memory
Memory nodes are written explicitly. You add a memory when a decision is made: "decided to use JWKS endpoint verification instead of static key, more flexible for key rotation." The AI proposes memories; you ratify them. Nothing is stored without your intent.
This is not the AI's memory, it is the project's memory, maintained by you and served to the AI. The AI is a consumer of the memory, not its author.
The ratification step is not overhead. It is the moment when a decision made in conversation becomes a persistent project constraint, auditable, version-controlled, and accessible to every future session.
Memory that survives rebuilds and re-scores
A Spiderbrain brain is rebuilt every time the codebase is re-scored. The Memory Tree is independent of the brain build. A memory about the JWT convention survives a complete re-score, a dependency update, or a major refactor.
This persistence is the core value: the memory is keyed to the project, not to the build. The decisions that matter, the ones you would have to re-explain to a new engineer or a new AI session, survive every change to the codebase itself.
Starting a fresh project
For a new project, the Memory Tree starts empty. The first session is context-free, but it is also the first session, so there is no accumulated context to lose.
The value compounds session by session. By session 5 or 10, the Memory Tree is already saving meaningful time and preventing meaningful errors. By session 20, it is the difference between a coherent codebase and a patchwork of decisions made by an agent that had no memory of its previous choices.