Every AI conversation starts from zero. Your projects, decisions, and preferences disappear as soon as you close the chat. Second Brain fixes that. It is a self-hosted memory layer that works with Claude, ChatGPT, Cursor, and any MCP client. You can store context once and recall it by meaning instead of keywords. It includes duplicate detection, semantic search, and a web UI. Built on Cloudflare, it offers a free tier and your data remains yours. MIT licensed.
This is the 2nd launch from Second Brain for AI. View more
Second Brain for AI v2
Launched this week
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.
Free
Launch Team / Built With
Second Brain for AI
@rahilpirani 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.
Second Brain for AI
@arturbrugeman 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.
@rahilpirani 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 ?
Second Brain for AI
@reda_roqai_chaoui 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.
Second Brain for AI
@noctis06 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.
@noctis06 Curious! How do you currently manage context across projects??
Hi @rahilpirani , 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.
Second Brain for AI
@vahid_davoudi 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.
@rahilpirani 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.
Second Brain for AI
@thenameisarian 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 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.
Second Brain for AI
@pooja_phillips 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.
@rahilpirani 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.
Second Brain for AI
@pooja_phillips 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.
@rahilpirani 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.
Second Brain for AI
Hi @pooja_phillips --
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: https://github.com/rahilp/second-brain-cloudflare/issues/190. I'm hoping to launch it in the next couple of weeks once I get all the right certs from Apple and for Windows.
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.
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.
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"?
Second Brain for AI
@kyo_shino 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.
@rahilpirani 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.
Second Brain for AI
@kyo_shino 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.
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?
Second Brain for AI
@avantigrowthlab 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?
Second Brain for AI
@saksham_salvi 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.
@rahilpirani 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.