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.
Replies
Prefactor
Is this open sourced?
Second Brain for AI
@ethan_lee8 Yes, MIT licensed.
does it provide any kind of api for that storage ?
Second Brain for AI
@kartikmalik 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.
the review's "what needs improvement" flags the Vectorize/Worker CPU ceiling under concurrent multi-hop recall - have you actually hit that limit at real personal-scale usage, or is it still theoretical?
Second Brain for AI
@sabber_ahamed Theoretical at personal scale. The bottleneck has been hop latency, not CPU. The ceiling becomes real when you layer concurrent multi-hop over conflict reconciliation at multi-tenant scale.
@rahilpirani hop latency over CPU is the more useful finding honestly, most people assume compute is the wall. is that network round trips between workers, or the traversal itself needing too many hops per query?
Second Brain for AI
@sabber_ahamed The traversal itself. Each hop is a sequential D1 read - you have to know which node you're at before you can follow the next edge. It's all in one Worker. Parallel edges at the same depth help, but depth itself is serial.
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?
Second Brain for AI
@sabber_ahamed User confirms it. Contradictions surface both writes as canonical vs draft, and you decide which stands. Re-reference frequency is a signal we track, but it doesn't automatically settle anything.
@rahilpirani makes sense to keep a human in the loop on that. does the conflict get surfaced right at write time, or does it stay quiet until you actually search across both versions?
Second Brain for AI
@sabber_ahamed At write time. The store operation itself returns the conflict notice, shows which memory is being superseded, and marks the newer one canonical. Nothing waits for a search.
Second Brain for AI
@sabber_ahamed Write time. The contradiction check runs on every write - if the new entry conflicts with an existing canonical, both surface immediately as a draft-vs-canonical pair. You see the tension the moment it's written, not later when you search.
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?
Second Brain for AI
@podcast_ai The distinction holds regardless of who writes. Agent writes that conflict with existing canonical memories surface immediately as a draft-vs-canonical pair at write time. Settling a draft to canonical is a human action. Agents write freely but can't settle context unilaterally.
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?
Second Brain for AI
@galdayan Correcting the root doesn't cascade. The graph shows you what linked off it, so the dependency chain is visible rather than hidden, but walking those downstream nodes is on you. The wrong-from-the-start case is harder than stale-over-time because there's no recency signal to catch it early - that's a real gap we're thinking about.
@rahilpirani makes sense that recency signal doesn't exist for a wrong-from-birth memory, there was never a moment it "went stale" to trigger on. that's a genuinely hard one, not just a scoring tweak. thanks for engaging with the edge case instead of just the easy one.
Second Brain for AI
@galdayan The edge cases are where the real design happens. Appreciate you pushing on it.
@rahilpirani good luck with v2, this was a genuinely thoughtful launch to dig into.
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?
Second Brain for AI
@henry_s_jung v2 doesn't auto-decay, but every write checks against existing canonical memories. Contradictory new context surfaces immediately as a draft-vs-canonical pair, so stale info gets flagged the moment something newer conflicts with it. The trickier case is memories that were wrong from the start and never contradicted - that's a real gap we're thinking about.
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?
Second Brain for AI
@noctis06 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.
Second Brain for AI
@chielephant 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
Second Brain for AI
@omri_ben_shoham1 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.