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

Self-hosting the memory layer in my own Cloudflare account is what makes me willing to put real project context in it — the data staying mine is the whole ballgame. The V2 "distinguishes settled decisions from drafts and stale context" line is the part I'd stress-test: when Claude and Cursor write conflicting versions of the same decision, does it auto-pick the newer one, or is there a confirm step so I decide what's canonical? And is recall scoped per-project, or does every connected MCP client pull from one global pool?

  Confirm step, not auto-pick. Contradictory writes from any client surface immediately as a draft-vs-canonical pair and you decide which stands. On scope: one global pool per user across all MCP clients. Tagging lets you filter recall by context today; per-project partitioning is on the roadmap.

Cross-tool memory is the piece I keep wanting and keep not trusting, mostly because I can never see what it decided to remember. Does Second Brain let me look at and edit the actual memory it's built, or is it a black box I have to take on faith? The moment one of these quietly remembers something wrong I lose the whole thread, so the inspect-and-correct part matters more to me than the recall.

  Not a black box. The web UI shows every memory: which tool wrote it, when, and its current status (canonical, draft, or deprecated). You can edit, unlink, or deprecate entries directly. Visibility came before recall in the design, for exactly the reason you named.

self-hosted and MIT licensed is the right call for something that's basically your whole context history - I'd never trust a memory layer like this if I couldn't see exactly where the data lives. the "canonical vs draft" distinction for handling contradictions is smart, most memory tools just let the newest write win and call it a feature

  Building it on your own Cloudflare account was the only architecture where trusting the memory layer isn't a leap of faith. The canonical vs draft decision follows the same logic - if you own the data, you should also own every decision about what overwrites what.

As a solo dev I burn the first ten minutes of every Claude and Cursor session re-explaining decisions I already made, so a self-hosted memory layer is something I'd actually run. The canonical-vs-draft split, so a newer write doesn't silently overwrite a settled decision, is the sharp part here — treating recency as truth is exactly how these memory piles rot. Running it on my own Cloudflare free tier basically seals it.

  Ten minutes per session adds up fast across tools. Running on your own Cloudflare free tier at personal scale without hitting limits was a design requirement, not a lucky side effect - glad that part lands.

The "connects dots across tools" framing resonates — I've been working on cross-session memory for fictional characters and hit the same wall: memory needs to know what contradicts what, not just accumulate. Does Second Brain handle conflict detection when the same topic appears differently across tools, or is resolution left to the user?

  Detection is automatic at write time. When Cursor writes something that conflicts with a canonical from Claude, both surface immediately as a draft-vs-canonical pair with source and timestamp attached. You see the tension the moment it's written. Resolution is yours to call - the system surfaces it, you settle it.

 That's a clean model — surfacing draft-vs-canonical at write time with source + timestamp is the right primitive. The case I keep hitting in my own domain (character memory for fiction) is a third one: not a hard conflict, but soft drift. "She's cautious" → "she took a risk once" → "she's a risk-taker." No single write trips a conflict detector, yet the canonical quietly erodes. Have you thought about drift as separate from hard conflict, or is that out of scope for tool-sync?

  Drift is a distinct case v2 doesn't handle. Contradiction detection needs an opposing signal to fire; drift has none because every write is locally compatible. The fix would be semantic distance scoring on writes against canonical - flag "close but subtly different" for review rather than letting it through silently. Character memory for fiction is the clearest framing of this problem, and the same erosion pattern shows up in agent memory too.

Semantic distance from canonical is where I'd start too — the hard part is the threshold. Too tight and you flag legitimate arc (a character is allowed to grow); too loose and slow erosion still slips through. What's helped me: weight the distance by how load-bearing the fact is. A character's core wound drifting should scream; a peripheral preference shouldn't. Same in agent memory — a few facts are structural, most are disposable. Would you expose that as a per-canonical "stability" weight, or keep it uniform?

That's a clean model — surfacing draft-vs-canonical at write time with source + timestamp is exactly the right primitive. The hard part I keep hitting in my own domain (character memory for fiction) is the *third* case: not a clean conflict, but a soft drift where the new statement doesn't contradict the canonical, it just slowly erodes it. "She's cautious" → "she took a risk once" → "she's a risk-taker." No single write trips the detector, but the canonical is gone. Curious whether you've thought about drift vs. hard conflict as separate problems, or if that's out of scope for the tool-sync use case.

That's a clean model — surfacing draft-vs-canonical at write time with source + timestamp is the right primitive. The case I keep hitting in my own domain (character memory for fiction) is a third one: not a hard conflict, but soft drift. "She's cautious" → "she took a risk once" → "she's a risk-taker." No single write trips a conflict detector, yet the canonical quietly erodes. Have you thought about drift as a separate problem from hard conflict, or is that out of scope for the tool-sync case?

  Soft drift is a distinct case v2 doesn't handle yet. Each write is compatible so nothing trips the detector, but the canonical erodes write by write. The fix would be semantic drift detection: compare incoming writes against existing canonical entries not just for contradiction, but for directional shift. It's further out on the roadmap than tool-sync. Your character memory framing is the clearest version of this I've seen.

How will you determine the period for detecting shift? Cautious → took a risk once → risk taker is seen as drift only relative to the original canonical version, not relative to the immediately preceding write, relative to its neighboring write, each step appears valid. However, go too far out with your window and you may end up calling real character development (character is entitled to become more adventurous) drift. Are you going to detect drift by using an anchor point, rolling window, or some kind of method to determine whether gradual evolution is taking place or unintended erosion is happening, and, if you have selected the latter approach, how will you detect that difference based on the write history alone?

  Anchor point is the right intuition. The canonical entry at time zero is the reference; each new write scores against that, not against the prior write. Rolling window has exactly the failure mode you describe: each step looks valid. The hard part is intent. Write history alone can't reliably distinguish evolution from erosion. The practical answer: surface the cumulative delta from the anchor so the drift becomes visible rather than silent, and let the user decide if it's growth or decay. Confirmation should update the anchor.

 That is precisely what I was thinking about. The comparison of everything to the canonical version instead of the latest change makes perfect sense. The confirmation is a good safety measure to make sure that evolution is not mistaken for drift.

Nice upgrade for the second shot bro. How does it resolve the conflict? Does it deterministic? What happen if (Could I) revert to history question because of decision changes or bad responses?

  Not deterministic - conflicts surface both sides for you to decide. Nothing gets deleted: deprecated memories stay in the audit trail and can be restored from the web UI.

I often work across multiple agents, but messages and memory are not shared between them, which means I need to frequently copy context back and forth. The appearance of Second Brain is truly a lifesaver!

  That context-copying tax is the exact problem Second Brain was built to eliminate. Really glad it's working for you!

@rahilpirani that "own the data, own the overwrite decision" framing makes sense. flip side of it being my Cloudflare account - if a bug on your end (not user error) corrupts the graph, is recovery also on me to have set up my own D1 backups/point-in-time recovery, or does Second Brain ship some backup mechanism by default so self-hosting doesn't quietly mean "you're also now responsible for your own disaster recovery"

  D1 has built-in export tooling, so you can snapshot the database on a schedule. Second Brain doesn't ship a backup layer on top of that. The honest answer: self-hosted does mean you own disaster recovery. The risk is manageable - D1 exports are one command - but it's real. Adding a one-click export to the web UI is on the roadmap.