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.

Persistent memory makes agents much more useful, but also raises interesting reliability challenges. How do you validate that outdated or incorrect memories don’t keep influencing future responses?

Maker

  Three mechanisms handle this: contradictory writes become drafts for review rather than silently overwriting settled context, canonical memories require explicit confirmation before they're superseded, and deprecated entries drop from recall but stay in the audit trail. Recency alone doesn't win.

 I like that approach, especially keeping deprecated memories in the audit trail instead of deleting them. Have you seen cases where the model still references deprecated memories indirectly, or has this approach eliminated that issue?

Maker

  The filter sits at the recall layer, so deprecated entries never reach the AI in the first place. The model only sees what recall returns. The one real edge case: if the old content was quoted or referenced inside a canonical memory before being deprecated, that canonical memory still surfaces. We treat it as a documentation problem rather than a filter bypass, and it has been rare in practice.

Maker

The history is the context. Knowing that a decision changed, when it changed, and what replaced it is different from just knowing the current answer.

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.

does it provide any kind of api for that storage ?

Maker

  Yes, two interfaces: MCP tools (remember, recall, search) for AI clients like Claude and Cursor, and a REST API for direct programmatic access. Both are documented in the GitHub repo README.

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.

Finally a memory layer that actually feels useful across different tools. Set it up with my Claude and Cursor workflows and the semantic recall saved me from re-explaining a project setup I had already detailed the day before.

Maker

  The re-explaining tax is the whole reason this exists. Glad the cross-tool recall is cutting it already.

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.

1234
Next
Last