Second Brain for AI v2

AI memory that connects the dots across every tool

Productivity

Developer Tools

Artificial Intelligence

GitHub

Visit WebsiteSee on Product HuntTwitter ⧉Github ⧉

I don't just build Second Brain. I use it every day.

Today I stored every comment, every piece of feedback you all left on the launch. Then asked it to tell me what v3 should focus on. That screenshot is the answer.

Top 5 on Product Hunt. Honestly didn't see that coming.

Thank you. Every comment, every upvote, every share, it's what makes building this worth it. You're not just users, you're shaping what this becomes.

v3 is already taking shape because of 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"

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!

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?

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?

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.

This solves a problem I hit constantly as a solo maker. I'm building a small Mac app + re-explaining architecture decisions, naming conventions, and "why we did it this way" every time a session resets gets old fast.

The canonical vs. draft distinction is the part that stands out to me. Most memory tools I've tried just let the newest note win, which is actually worse than no memory when two sessions disagree. Curious how it behaves for a single-developer, multi-tool setup like mine specifically; is there any overhead to set up for someone who isn't running a team, or is the self-hosted Cloudflare piece basically "connect once and forget about it"?

One thing I noticed: there's no simple hosted webpage to just sign up and go — it looks like setup is done directly through git/deploying to your own Cloudflare account. Was that a deliberate choice to keep it self-hosted and avoid managing user data yourselves, or is a simpler no-code setup on the roadmap for people who aren't comfortable with git?

Also: does it pick up context automatically as I work, or do I need to explicitly tell it "remember this" for a decision to stick?

Nice to see self-hosted taken seriously here rather than another tool that wants my data in someone else's cloud.

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?

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"?

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.

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

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.

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?

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?

Interesting take on memory. The part I keep running into with long lived AI memory is not storage, it's that old memories go stale and quietly become wrong later. Curious how v2 handles that, do memories decay over time or get re checked against newer context?

the deprecation/audit-trail design is solid for handling info that goes stale over time. different case though: what if a memory was just wrong from the start (bad transcription, hallucinated detail from the source tool) and by the time you catch it, three other memories have already linked off it as if it were true? does correcting the root node also flag or re-check what was built on top of it, or is that on the user to notice and untangle manually?

I run most of my business ops through AI agents day to day, and the "newer isn't always more correct" framing matches exactly what I see — tools overwrite settled decisions with whatever happened last. Curious: when memories are written autonomously by agents rather than by me in a chat, does the canonical/draft distinction still hold up, or does it assume a human is doing the confirming?

the settled-vs-draft distinction is the part I'd want to poke at - is that inferred from how often a decision gets re-referenced across sessions, or does the user have to explicitly mark something as settled?