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

Second Brain for AI v2 - AI memory that connects the dots across every tool

by
•
Second Brain remembers your projects, people, decisions, and preferences across Claude, ChatGPT, Cursor, Codex, and any MCP client. V2 automatically links related memories, follows those connections during recall, and distinguishes settled decisions from drafts and stale context. Open source and self-hosted in your Cloudflare account.

Add a comment

Replies

Best
Maker
📌
Hi Product Hunt, Three weeks ago, I launched Second Brain for AI here. It finished #3 Product of the Day, but the most valuable part of the launch was not the ranking. It was the comments. You told me that newer information is not always more correct. You asked what happens when Claude and Cursor save conflicting versions of the same project decision. You described the need to compress long conversations without losing their through-line. You pushed me to make self-hosted deployment easier to understand. Those comments became the roadmap. The first version gave Claude, ChatGPT, Cursor, and other MCP clients one persistent memory layer. You could store context once, retrieve it by meaning, and keep the data inside your own Cloudflare account. Today I am launching v2. Second Brain now builds a self-organizing knowledge graph from your memories: - related memories link automatically as they are saved - multi-hop recall follows those links beyond the closest semantic match - an interactive graph shows how projects, people, decisions, preferences, and ideas connect - canonical, draft, and deprecated states separate settled knowledge from exploration and stale context - episodic and semantic classification distinguishes events from durable knowledge - hybrid retrieval combines semantic and keyword recall - contradiction-aware ranking prevents recency from automatically becoming truth - semantic compression preserves the important through-line as context grows The core promise has not changed. Second Brain is still one open-source memory layer for every AI tool you use, deployed into your own Cloudflare account and designed to run on the free tier at personal scale. V1 made memory persistent. V2 makes it connected and more trustworthy. I would especially value feedback on three things: 1. Are the automatically created relationships accurate enough to trust? 2. Does multi-hop recall surface useful context that ordinary semantic search misses? 3. Does the graph help you understand your memory, or is it only visually interesting? Thank you to everyone who commented, tested the product, opened an issue, followed the first launch, or shared Second Brain with others. You helped shape this release.

 Hi Rahil, the hard part with cross-tool memory has always been trust, not recall. When it answers, I want to know which source it pulled from so I can sanity-check before acting on it. Do you surface provenance per answer, or is it more black-box synthesis? In my experience that one distinction decides whether a team actually adopts it.

Maker

  Each recalled memory surfaces with its source metadata: which tool wrote it, when, and its status (canonical, draft, or superseded). The AI gets individual entries, not a blended summary, so it can tell you exactly where each piece came from. You're right that this is the distinction that decides adoption.

 It's really nice to see how much the product has changed based on user feedback. Memory is only useful if the system can tell the difference between updated information and conflicting information. How do you know when an old memory is outdated ?

Maker

 Contradictory writes become a draft vs. canonical pair rather than silently overwriting, so you decide which stands. Explicit updates mark old entries superseded and pull them from recall. The gap we haven't solved: memories wrong from the start have no recency signal to catch them - that's one we're actively thinking about.

Confirm-step is the right default - I'd rather resolve a conflict than have recency silently win. The one-global-pool part is what I'd pressure-test: if tagging only filters recall, does a draft-vs-canonical conflict from a throwaway experiment still surface while I'm working in an unrelated project, or does tagging also scope where contradictions get raised? Per-project partitioning landing would basically remove that worry.

Maker

  Today tagging scopes what you recall, not where conflicts surface - a draft-vs-canonical pair from a throwaway experiment lives in the global pool and can show up anywhere. Per-project partitioning is specifically the fix for this: conflicts would only raise within the partition they belong to. It's on the roadmap because your pressure-test is exactly the right one to run.

 Curious! How do you currently manage context across projects??

Hi  , congrats on v2.

I like that you turned launch feedback directly into the roadmap. The newer information is not always more correct point is especially important for memory products, because stale-but-confident context can be worse than no memory at all.

The canonical / draft / deprecated states feel like the strongest part here. That gives users a way to trust the memory layer instead of treating it as a black box.

Curious how often users need to manually correct the graph before it becomes reliable.

Maker

  The first few weeks see the most corrections while the canonical layer is getting established. Once you have settled decisions in place, contradictions have a clear reference point to surface against and the conflict rate drops. Reliability tracks density of canonical entries more than time.

 That makes sense. I like the idea that reliability depends more on the density of settled canonical entries than just time. Seems like that also gives users a clearer path to trust the system instead of waiting for it to “magically” get better.

the "newer information is not always more correct" insight is the entire challenge of persistent AI memory in one sentence. most memory systems assume monotonic updates and break the first time claude and cursor disagree.

real q: when claude asserts one project decision and cursor asserts a different one hours later, does second brain surface both with source + timestamp, or resolve automatically? asking because the resolution logic IS the product — everything else is storage.

Maker

  Both surface, but not equally. Canonical memories are protected, so the contradictory Cursor write comes in as a draft for review rather than a silent overwrite. You confirm it supersedes the original or deprecate it. Deprecated memories drop from recall but stay in the audit trail. No tool wins by being last.

This is a strong direction. The interesting part isn’t just “memory,” it’s whether the system can tell what is still true vs what was only temporary context.

I like the idea of separating settled decisions from drafts and stale context. That feels essential if AI memory is going to be useful across tools instead of slowly becoming a pile of old assumptions.

Curious how you handle corrections when the memory graph connects something wrong.

Maker

  Corrections work on two layers. When the graph forms a bad link, you can remove it directly from the Related list (one tap in the web UI) or via the unlink MCP tool. Weak links also get pruned automatically as evidence thins. For the truth vs temporary context question, canonical entries mark what's settled and are protected from silent overwrites. Drafts hold contested context until confirmed.

How does the semantic search actually decide what to pull in when context is ambiguous, and does it ever surface stale info that you've already updated somewhere else?

Maker

  Hybrid retrieval (semantic + keyword) handles ambiguity, with graph links as a tiebreaker when signals are close. Stale entries are filtered at the recall layer: deprecated and superseded memories never reach the AI.

Finally something that solves the most frustrating part of using AI. Plugged it into Claude and Cursor and the recall by meaning actually works, way better than digging through old chats. Love that it's self-hosted too.

Maker

  The recall-by-meaning piece was the hardest to get right. Glad it's landing as actually useful rather than just technically interesting.

What is the diff with a simple obsidian vault?

Maker

  Obsidian is notes you write for yourself. This is memory AI tools write automatically across Claude, ChatGPT, and Cursor, recalled by meaning rather than keyword search.

congratulations. Do you figure that the customer for the second brain is the user or their agents or external people?
Maker

  The user. Agents are the interface, writing and recalling on your behalf. External sharing is out of v2 scope.

The linked-memory approach is compelling, but I think the harder problem isn't remembering more—it's remembering the right things.

How does v2 decide that a decision is "settled" versus something that should remain tentative? It seems like getting that boundary right could matter more than the size of the memory graph, especially when AI starts reusing old context automatically.

Congrats on the launch! 🚀

Maker

  v2 doesn't decide on its own. Contradictory writes become drafts for your review, not silent overwrites. You confirm what's settled. The boundary stays with you; the system just makes the tension visible.

 That's an interesting distinction.

It actually made me think of a second-order consequence I hadn't considered before. If that assumption holds, it changes where I think products like this create trust over time.

Maker

  Curious what consequence you're thinking about. That kind of observation usually points at something real.

Interesting idea. How do this scale efficiently? Is there an indexing or meta layer so as I have more info to save? What about "split personalities?" There's work info, personal info, hobby info, etc that tend to be fairly siloed. Does it figure out my silos over time?

Maker

  Vectorize keeps recall latency flat as memory grows. On silos: v2 doesn't auto-partition yet. You can tag memories by context, but the graph links across domains when memories are semantically close. Automatic partitioning is on the roadmap.

Your contradiction handling all keys off a competing signal — a second write disagrees, so it comes in as a draft. The case that bites me running a hand-curated file memory for my own agent has no such signal: a memory that was true when I wrote it, now false because the code moved underneath it, and nothing ever contradicted it. No competing write to open a draft, no reason to deprecate — it stays canonical and reads as trustworthy.

You told Gal wrong-from-the-start is hard because there's no recency signal. This is its sibling: right when written, wrong now, still no signal.

My only patch: stop treating recall as ground truth. Every entry reaches the model stamped with its age and a "verify before trusting" note, so even settled memory lands as a point-in-time claim.

So does v2 pass age through to the model at recall, or does "canonical" itself read to the model as "trust this"?

Maker

  Age passes through. Every recalled memory surfaces with its write timestamp and current status. Canonical means a human confirmed it, not that the model should treat it as current truth.

The silent staleness case you're naming is real and not solved in v2. Your patch of stamping every recall with age and treating it as a point-in-time claim is the right direction. Worth building as a first-class feature.

  makes sense — canonical = a human confirmed it, not "current truth." The part that caught me out in my own setup: passing the timestamp through wasn't enough on its own. The model still leaned on a 40-day-old canonical entry until the recall carried an explicit "point-in-time, verify before asserting" note right next to the age — the bare timestamp didn't change how it behaved. So for me the age metadata only started mattering once it came with a consumption-side nudge to actually discount it. Anyway, glad the staleness case landed — curious to see where you take it in v2.

Maker

  The model ignoring bare timestamps tracks. Timestamps are metadata, not reasoning instructions. "Point-in-time, verify before asserting" alongside the age is the actual signal that changes behavior. Building that note into the recall output format rather than leaving it to the prompt is the obvious next step. Adding it to the roadmap.

123
Next