Second Brain for AI
Persistent memory for Claude, ChatGPT & Cursor. Free.
Start new thread

How far should an AI follow your memory graph?

by•

One of the hardest decisions in Second Brain v2 was deciding how much related context recall should include.

Imagine asking:

"What did we decide about the Product Hunt launch?"

A normal search might find the launch plan.

A graph-aware system could also find:

  • the positioning decision connected to it

  • feedback that changed the launch date

  • the demo you created afterward

  • a previous community post that performed well

  • an older decision that has since been replaced

That can be genuinely useful. It can also become noisy very quickly.

Second Brain handles this by ranking direct matches first, then expanding through connected memories with distance decay. The further away a memory is, the more evidence it needs to appear.

I want the graph to recover context you forgot existed, without making every answer feel like a tour of your entire database.

Where would you set the default?

  1. Direct matches only

  2. Direct matches plus one connection

  3. Follow several connections when confidence is high

  4. Let the AI decide each time

Second Brain v2 is live today, and this is one of the areas where I would especially value feedback.

67 views

Add a comment

Replies

Best

I've used knowledge tools where everything gets connected and it sounds impressive at first. But after a while I realized I don't need more information I need the right information at the right time.

  That's what the ranking is for. Direct matches always score above connected memories, so the right answer comes first. The graph adds context when direct evidence is sparse - it doesn't pile on top of a clear answer.

I like the distance decay idea. How will users adjust recall depth for different projects because one setting may not fit everyone?

Global setting for now. The MCP already exposes the hops parameter directly so you can tune it per call. Per-project presets are on the list.

me would start with one connected memory. users could expand further only when they need extra background and supporting details.

That's the current default. One hop keeps it tight without pulling in things you didn't ask for.

I think 🤔 SB v2 supposed to do exactly what you are doing here : ask us and let us to choose how deep and how far we want to go !

That's the direction. The hops parameter is already configurable per MCP call. Next step is surfacing it as a user-facing setting rather than a developer option.

I would probably choose option 3. There have been many times when I remembered one decsion but completely forgot the discussion that led to it. Bringing in related context only when the confidence is high feels like a good balance between helpful and overwhelming

Option 3 is the one I keep revisiting. The way it works now: score decays per hop, so deeper connections only pull through if the link is genuinely strong. Direct matches always win. Whether the decay is calibrated right is exactly what real usage will tell.

i like the distance decay idea because not every connected memory deserves equal attention. Showing the strongest matches first while keeping weaker links in the background sounds like a thoughtful approach.

If I had to pick one, I'd go with letting the AI decide, but only if users can easily see why each memory was included. A little transparency would build much more confidence in the results

I would probably choose direct matches plus one connection as the default. It gives me enough background while keeping the answer quick and useful.