As projects grow, so does the Memory Tree. By the time a significant project is six months old, the tree might have 40 or 60 memory nodes: architectural decisions, team conventions, third-party constraints, legacy debt warnings, pattern definitions.
Dumping all of that into every AI session is worse than dumping none of it. A 60-node context brief buries the relevant decisions in noise. The model’s attention is distributed across everything rather than concentrated on what matters for the current task.
Spiderbrain solves this with scoped memory recall: the AI gets the decisions that are relevant to the files it is about to touch, and nothing else.
How memory scope is determined
Every memory node in the Memory Tree is anchored to a scope: a specific file, a module, a directory, or a cross-cutting concern tag. When an MCP session begins and the AI has indicated which files it is working on, Spiderbrain computes the relevant memory set:
- Memories anchored to the specific files being edited
- Memories anchored to the modules those files belong to
- Memories anchored to any community that includes those files
- Cross-cutting memories tagged as globally relevant (team conventions that apply everywhere)
The result is a brief, a structured set of memory nodes that applies to this session’s task. Unrelated memories are not included.
The token economics
A full 60-node memory dump costs roughly the same as pasting 3,000 words of text into the context. That cost is paid before the AI writes a single line of code or answers a single question. It also degrades the model’s performance on the actual task: "lost in the middle" effects mean that relevant information buried in a long context gets less attention than information near the top or bottom.
A scoped brief for a task touching two or three files typically contains 5, 10 memory nodes, the decisions genuinely relevant to those files. The context cost is minimal. The signal-to-noise ratio is high. The model’s attention is directed at the right facts.
What the brief looks like
When your AI client connects to Spiderbrain over MCP and begins a session on auth/session.js, the scoped brief it receives might look like:
- "JWT is verified with RS256 against the JWKS endpoint. Never use HS256."
- "Session tokens expire in 24 hours. No sliding expiry."
- "The refresh token is single-use and rotated on each use."
- "Do not add logging to this module, it is security-sensitive and logging here creates a PII risk."
These four decisions are directly relevant to modifying auth/session.js. The 40 other decisions in the Memory Tree about the queue, the data access layer, and the frontend conventions are not served.
Cross-cutting memories
Some decisions apply everywhere: "all API responses use the standard envelope", "never throw raw exceptions, always wrap in the team’s error type", "the repo uses named exports only, never default exports." These are anchored as cross-cutting concerns and appear in every scoped brief.
The cross-cutting set should be small by design, 5, 10 decisions at most. If everything feels like a cross-cutting concern, the memory scoping breaks down and you’ve recreated the "dump everything" problem with extra steps.
Memory scoping as onboarding
For a new team member or a new AI session working on an unfamiliar part of the codebase, the scoped brief serves as an instant contextual orientation: "here are the decisions you need to know before you touch this module."
This is faster and more reliable than reading the module’s comments, more accurate than inferring conventions from existing code, and more complete than asking a senior engineer who might forget to mention the constraint that cost them a day six months ago.
The Memory Tree makes institutional knowledge queryable and scopeable. Scoped recall makes it usable without overwhelming the agent receiving it.
