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
Launching today
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.
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.
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.
How does the semantic search actually decide what to pull in when context is ambiguous, and does it ever surface stale info that you've already updated somewhere else?
Second Brain for AI
@zcankekozpdmd Hybrid retrieval (semantic + keyword) handles ambiguity, with graph links as a tiebreaker when signals are close. Stale entries are filtered at the recall layer: deprecated and superseded memories never reach the AI.
This is a strong direction. The interesting part isn’t just “memory,” it’s whether the system can tell what is still true vs what was only temporary context.
I like the idea of separating settled decisions from drafts and stale context. That feels essential if AI memory is going to be useful across tools instead of slowly becoming a pile of old assumptions.
Curious how you handle corrections when the memory graph connects something wrong.
Second Brain for AI
@vahid_davoudi Corrections work on two layers. When the graph forms a bad link, you can remove it directly from the Related list (one tap in the web UI) or via the unlink MCP tool. Weak links also get pruned automatically as evidence thins. For the truth vs temporary context question, canonical entries mark what's settled and are protected from silent overwrites. Drafts hold contested context until confirmed.