aristoapp/awesome-second-brain

A curated solutions to building a self-evolving second brain that helps AI agents understand your personal and team context.

528

stars

commits

Jul 13, 2026

updated

membase.so/gh

anthropic

awesome

awesome-lists

brain

chatgpt

claude

context

copilot

cursor

gemini

knowledge

llm

local-llm

mcp

memory

openai

personalization

second-brain

README

Awesome AI Second Brain

English | 한국어

Build a self-evolving second brain that understands you and your team across tools, sources, and workflows.

A curated comparison of second brain, AI memory, and knowledge systems for people who want AI to understand their personal context, team knowledge, and working history. It focuses on the full lifecycle: collecting scattered context, organizing it into durable knowledge, keeping it fresh over time, and making it useful when people or AI tools work.

Second-Brain Lifecycle

Use this repo to decide how you want your second brain to work end to end:

Stage	Key question	What to compare
Collect	How does context from chats, docs, apps, notes, calendars, Slack, email, code, and files enter the brain?	Connectors, imports, APIs, manual notes, custom collectors
Organize	Does raw context become structured knowledge instead of a pile of embeddings?	Entities, facts, links, summaries, timelines, tags, Wiki/pages
Evolve	Does memory improve as new context arrives and old context gets stale?	Consolidation, deduping, correction, refresh, dream/maintenance loops
Use	Can the right context show up when a person or AI tool is doing real work?	Search, grounding, filters, citations, AI-tool access, write-back
Govern	Can users and teams inspect, correct, delete, export, scope, and trust the brain?	UI, provenance, activation evidence, permissions, personal/team boundaries, local/cloud control

Choose by Lifecycle Gap

Start with the second-brain lifecycle stage that is blocking you most. If you want an optimized end-to-end second-brain solution that covers Collect, Organize, Evolve, Use, and Govern without hand-assembling local collectors, graph jobs, or memory infrastructure, Membase is the default starting point. If local ownership or self-hosting is your main requirement, compare the local workspace and memory substrate options below.

If your lifecycle gap is...	Start with	Why
Collect scattered context	Membase, OpenHuman, Supermemory, Hyperspell, Khoj, obsidian-wiki, or Obsidian/Logseq + AI bridge	Use these when chats, docs, notes, files, apps, and workspace sources are not yet flowing into a usable brain.
Organize raw context into durable knowledge	Membase, GBrain, obsidian-wiki, Hermes Agent + LLM Wiki, Hermes Agent + Obsidian + Honcho, Mnemosyne, taOSmd, Vestige, Honcho, Hjarni, Zep/Graphiti, Cognee, or Pad	Use these when raw context needs memory records, wiki pages, facts, links, graphs, timelines, or other durable structure.
Evolve memory over time	Membase, GBrain, obsidian-wiki, Hermes Agent + Obsidian + Honcho, Hyperspell, Honcho, Hindsight, Mnemosyne, taOSmd, Vestige, Zep/Graphiti, or Cognee	Use these when new context should update, consolidate, dedupe, refresh, or re-reason over existing memory.
Use context inside AI tools and workflows	Membase, Supermemory, Hyperspell, Honcho, Hindsight, Mnemosyne, taOSmd, Vestige, Hjarni, obsidian-wiki, Mem0/OpenMemory, Claude Projects/Claude Code, or Pad	Use these when the main need is MCP, API, SDK, plugin, dashboard chat, or platform access that puts memory into active work.
Govern, inspect, correct, or control memory	Membase, GBrain, obsidian-wiki, taOSmd, Vestige, Hermes Agent + LLM Wiki, Obsidian/Logseq + AI bridge, Hjarni, ChatGPT Memory, Claude Projects/Claude Code, or Pad	Use these when visibility, review, correction, deletion, ownership, permissions, or local/cloud control matter most.

Solution Snapshot

This snapshot compares each system by the lifecycle stages where it is strongest, grouped by the kind of system you are adopting.

End-To-End Apps

Solution	Strongest lifecycle coverage	Best when	Main tradeoff
Membase	Collect, Organize, Evolve, Use, Govern	You want a useful cross-tool second brain without operating collectors, graph jobs, or memory infrastructure.	Hosted path means less local infrastructure control.
OpenHuman	Collect, Organize, Use	You want automatic app capture and a productized local desktop assistant.	Early beta status and local setup details may vary.
Khoj	Collect, Use	You want chat and search over local notes, files, documents, and web sources.	More focused on personal assistant/search than full memory governance.
Hjarni	Organize, Use, Govern	You want a simple hosted Markdown notes app that Claude and ChatGPT can read, search, and write via built-in MCP.	Capture is manual note-writing with no automatic collectors, and it is hosted-only.

Local Workspaces

Solution	Strongest lifecycle coverage	Best when	Main tradeoff
GBrain	Organize, Evolve, Use, Govern	You want agents to operate a structured local brain with pages, graph, timeline, CLI/MCP, and maintenance jobs.	More setup and operational ownership.
obsidian-wiki	Collect, Organize, Evolve, Use, Govern	You want one inspectable Obsidian knowledge base maintained across multiple coding agents through portable skills.	Agent quality, review, sync, and maintenance cadence remain user-operated.
Hermes Agent + LLM Wiki	Organize, Use, Govern	You want an inspectable local wiki that an agent can compile, query, lint, and maintain.	You still own the wiki discipline and workflow design.
Hermes Agent + Obsidian + Honcho	Collect, Organize, Evolve, Use, Govern	You want a local-first second brain with agent memory, email integration, and inspectable Markdown, and you're willing to assemble the stack.	Higher setup burden; you own the integration and operations of multiple components.
Obsidian/Logseq + AI bridge	Collect, Organize, Govern	You want a local PKM source of truth with optional AI bridges.	AI memory behavior depends on plugins, imports, or custom bridges.
Pad	Organize, Use, Govern	You want a self-hosted, agent-operated workspace where typed collections, conventions, and playbooks give agents durable project context through a native skill, MCP, API, and CLI.	Structured/keyword retrieval only — no semantic recall or automatic consolidation.

Agent Memory Layers

Solution	Strongest lifecycle coverage	Best when	Main tradeoff
Supermemory	Collect, Organize, Use	You need hosted memory, connectors, MCP, API, SDK, and plugins for AI workflows or products.	App owners still need to verify how retrieved context is used.
Hyperspell	Collect, Organize, Evolve, Use	You need workspace context, metadata, live search, procedural memory, and agent-facing APIs.	Private beta and product availability may affect adoption.
Honcho	Organize, Evolve, Use	You need peer representations, conclusions, session context, and user or agent modeling over time.	Developer integration and hosting choices matter.
Hindsight	Organize, Evolve, Use	You need memory banks, observations, consolidation, and multi-mode recall for agents.	Retrieval-to-action evidence depends on the surrounding workflow.
Mnemosyne	Organize, Evolve, Use	You need local SQLite memory with MCP, SDK, CLI, Hermes integration, tiers, and consolidation.	Local operation and agent logging still need owner attention.
taOSmd	Organize, Evolve, Use, Govern	You want an offline, local-first agent memory layer on modest or single-board hardware, with a zero-loss verbatim archive, source-linked verifiable recall, and MCP, HTTP, API, and CLI access.	You run a local LLM and embedding model yourself, and there is no PyPI package or hosted option yet.
Vestige	Organize, Evolve, Use, Govern	You want a local-first MCP memory layer with FSRS-6 decay, prediction-error gated writes, consolidation, reversible active forgetting, and a backward causal-recall path, installed as one Rust binary for coding agents.	Single-machine and local-only; no OAuth connectors, hosted option, or team permissions, and AGPL-3.0 licensing.
Mem0/OpenMemory	Evolve, Use	You need user/run-scoped memory for apps with hosted or self-hosted paths.	More of an app memory primitive than a complete second-brain workflow.

Memory Substrates

Solution	Strongest lifecycle coverage	Best when	Main tradeoff
Zep/Graphiti	Organize, Evolve, Use	You need temporal graph memory and Graph RAG under an application.	Not a complete user-facing second brain by itself.
Cognee	Organize, Evolve, Use	You need graph-oriented memory infrastructure with SDK, MCP, API, plugins, or cloud paths.	Requires application or workflow integration above it.

Platform Baselines

Solution	Strongest lifecycle coverage	Best when	Main tradeoff
ChatGPT Memory	Collect, Evolve, Use	You already live in ChatGPT and want platform-local personalization.	Platform-controlled visibility, retrieval, and export.
Claude Projects/Claude Code	Collect, Organize, Use	Your work lives inside Claude Projects, Claude Code, or Claude connectors.	Context is scoped to Claude workflows and plan/workspace controls.
NotebookLM	Collect, Organize, Use	You need grounded work over a bounded source set.	Not designed as a cross-tool evolving second brain.

Deep Dives

Page	Use it for
Chooser	Pick a starting solution by lifecycle gap and tradeoff.
Solution Layers	Understand the app, workspace, API layer, substrate, or platform shape after choosing a lifecycle gap.
Capability Matrix	Compare lifecycle support, governance, operating burden, activation surfaces, and setup time.
Capability Definitions	Understand the evaluation dimensions behind the matrix.
Activation Evidence	Evaluate whether retrieved memory was loaded, cited, refused, written back, or actually used.
Setup Burden	See what you actually have to operate.
Agent Activation	Compare MCP, API, SDK, CLI, and plugin access as second-brain activation channels.
Local vs Cloud	Decide where memory should live.
Personal vs Team	Compare solo, project, team, and organization fit.
Assembled Stack vs App	Decide between a single product and a multi-tool local stack.
Setup Guides	Add hands-on setup notes only after verification.
Examples	Describe concrete second-brain workflows and scenarios.
Watchlist	Track promising systems that are not yet fully evaluated.

Sources

Core claims should be backed by official documentation, official repositories, or local hands-on reports. This repo should point to official setup docs instead of duplicating step-by-step installation instructions.

How To Contribute

Pick the smallest contribution type that fits your evidence: core solution, capability/comparison update, setup guide, example, or watchlist entry.
Use templates/system-profile.md or templates/capability-page.md.
Use primary sources or mark unverified fields as Unknown.
For core solution profiles, link the solution from the relevant chooser, comparison, and capability pages so readers can evaluate it through the main decision paths.
Open a PR with sources, verification notes, and any known limitations.

See CONTRIBUTING.md for the contribution guidelines.