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

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! πŸš€

Β  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.

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

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

Β  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.

Β  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.

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.

Β  Solo setup is basically deploy once and it runs. The Cloudflare deployment was a deliberate call - self-hosting means you own the data and I don't. A simpler no-code path is on the roadmap; the git step is the main friction point I hear from non-devs. On capture: the AI tools write memories as they work, so most context is automatic. You can also say "remember this" explicitly for decisions you want to be sure stick. Either way ends up in the same graph.

πŸ”Œ Plugged in

 Thank you, Rahil! You're actually the first maker to reply to me here, which feels pretty special and definitely earns you a follow. 😊

I'm much more of a front end builder. Git still feels a bit overwhelming for someone who's mostly design with a bit of coding experience + "digitally minded".

Your approach to memories is really interesting. Do you see memory becoming a much bigger part of AI over the next few years? I'm curious what trends you're seeing and where you think persistent memory is headed as AI becomes more integrated into our daily workflows.

Β  Memory is moving from optional to foundational. As agents get more autonomous, they need context they can't re-ask for every session - that gap between what a model can do and what it reliably knows is where memory becomes load-bearing. The direction I see: toward memory that works more like judgment than storage, knowing what to surface, what's settled, what to question.

Β As someone who thinks a lot about UX UI, I wonder if the real challenge becomes less about remembering everything and more about remembering theΒ rightΒ things at the right time. Almost like memory evolving from a passive archive into an active collaborator that understands context, priorities, and even when not to interrupt.

Hi --

Thank you again for your feedback! I just finished the first version of the mac app installer/app. With this new app, you can install Second Brain without knowing anything about github and then use the same app to interact with your second brain. Thank you again for your recommendation... I heard you!

You can see the Github issue here: . I'm hoping to launch it in the next couple of weeks once I get all the right certs from Apple and for Windows.

Is this open sourced?

Β  Yes, MIT licensed.

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?

Β  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.

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

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

Β 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.

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

Β 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.

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

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

Β  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.

Β 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.

Β  The edge cases are where the real design happens. Appreciate you pushing on it.

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

Β  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.