What Is an AI Second Brain? What Goes In It, How AI Reads It, and How to Start

An AI second brain is a place outside the AI model where your knowledge and work live, which the AI apps you use can read and add to so you stop re-explaining. It differs from a notes app used only by you because the AI is a reader and writer too. The aim is continuity: a new conversation or a different assistant can pick up the same work.

Picture opening a fresh chat about a project you worked on yesterday. Instead of describing the client, repeating the rules and digging up the last draft, you ask the assistant to read the project record. It finds the background, the choices already made and the next step, then checks with you about anything unclear.

Where the second-brain idea comes from

The name comes from personal note-taking: Tiago Forte’s 2022 book Building a Second Brain is about keeping knowledge outside your head for your own use. The AI version adds another reader and writer to that record. You still choose what matters and correct mistakes; an assistant helps find, connect and update the material.

What goes in an AI second brain

Start with what you regularly need to explain again, rather than everything you could collect. A useful second brain has five kinds of material. They answer different questions, so give each a clear home.

• Reference material: documents, notes, research and sources. These answer “what do we know?” Keep a link to the original when you save a summary, so you or an assistant can check it later.
• Decisions and their reasons: what a person chose, why, and which alternatives were ruled out. These answer “why are we doing it this way?” A decision needs to be distinguishable from an assistant’s suggestion.
• Rules: how the work must be done, including limits an assistant must respect. These answer “what should happen every time?” A short instruction such as “ask before contacting a client” is more useful than hoping the assistant infers it.
• Projects and tasks: the goal, what is open, who is responsible and what is finished. These answer “what are we doing?” Separate a task you intend to do from an idea you merely discussed.
• Where you left off: the current state, next step and anything waiting on a person. This answers “where do I begin?” It should be short enough to read at the start of the next session.

The last four are the work itself. They are often what you lose most when you switch AI tools: you can find the original report again, but not the reason you rejected one approach or the unfinished check you meant to run. Saving a whole conversation makes that information available somewhere; writing a short record makes it usable.

For a student, that might mean research sources beside the essay outline, the chosen argument and tomorrow’s reading. For a designer, it might mean the brief beside approved choices, revision tasks and the last client question. The contents change, but the test stays the same: could another assistant start without asking you to reconstruct the project?

How an AI reads it: search or open the record

There are two common ways to give an assistant the right material. One searches a collection for relevant passages; the other opens a known record directly. Most good setups use both, because finding background and checking the current rules are different jobs.

Search documents by meaning

Suppose you ask what your research says about customers leaving during sign-up. A search by meaning can find a passage about people abandoning registration even when your exact words do not appear. The useful passages are handed to the model alongside your question.

This is retrieval: finding stored information for the current question. RAG, short for retrieval-augmented generation, means the AI uses that retrieved material to write its answer. Our guide to what RAG is explains the process; agent memory vs RAG explains why searching documents is only one part of remembering work.

Open structured records through a connector

For a task or a rule, you often know what to open: this project’s current instructions, its active tasks or its latest progress note. A connector lets an assistant request those records directly and, when allowed, update them. MCP, the standard way an AI app connects to outside tools, is one way to do this; see what MCP is.

Search helps with “find the research about this topic.” Opening a record helps with “show the decision that applies to this project.” Combining them lets an assistant check the rules first, read the current task, and then search the supporting documents instead of treating every old note as equally current.

Karpathy’s LLM Wiki: a concrete example

One example is Andrej Karpathy’s llm-wiki gist↗ (opens in a new tab), created April 4, 2026 and described as “A pattern for building personal knowledge bases using LLMs”. An LLM is a large language model, the kind of AI that reads and writes text. In this pattern, the model helps maintain a readable wiki rather than only answering questions about a pile of files.

The pattern separates raw sources, which the model reads but never changes, from a wiki of markdown pages, which it writes and keeps up to date. Markdown is plain text with simple formatting. A schema file such as CLAUDE.md or AGENTS.md sets the structure, an index.md catalogs the pages, and a log.md records activity by adding new entries without rewriting old ones.

It has three operations: ingest, query and lint. Ingest brings source material into the wiki; query uses the wiki to answer questions; lint periodically checks for contradictions, stale claims and orphan pages, meaning pages left unconnected to the rest. The wiki is browsed in Obsidian and built with an assistant such as Claude Code or Codex.

The gist contrasts this with RAG: instead of rediscovering knowledge from raw files for every question, the wiki is compiled once and kept current. That gives “Karpathy second brain” a specific meaning here: an AI-maintained knowledge base with source material kept separate. You can judge whether that pattern suits your research without treating it as the only way to build a second brain.

A personal brain or a company brain?

A personal second brain serves your own reading, thinking and work. A company brain is the same basic idea shared by a team: one record that each teammate and their AI can use. It needs more than access to a shared folder, because people also need to know which instructions apply and who can change them.

Give each piece of work its own project, whether it is client work, a product, marketing or operations. Put the rules where every teammate’s assistant reads them, and keep a record of who changed what. That makes it possible to ask whether a choice was approved by a person or only proposed by an AI.

A shared brain should not mean everyone can read everything. Decide who needs each project and who can edit its rules before adding assistants. AI memory for teams covers the difference between personal recall and a shared record the team can trust.

Your options, grouped by the job they do

These are different starting points rather than a ranking. Choose around the thing you keep losing, and only add another tool if it solves a separate problem.

• Built into one AI app: Claude Projects and memory, or ChatGPT Projects and memory. The context stays inside that app. See Claude project memory and ChatGPT project memory. This can be enough if you work in one place.
• Notes you connect yourself: Obsidian or Notion, with a collection of notes the AI reads. The wiki pattern above is one example of arranging that work. Choose this route if you want to maintain the structure and decide how the assistant reads and updates it.
• Personal memory tools: MemoryPlugin keeps facts about you, preferences and past chats across AI apps; myNeutron saves material you read and browse. See MemoryPlugin alternative and myNeutron alternative for when to keep a personal memory tool.
• Memory engines for developers building AI apps: Mem0 extracts facts from conversations; Supermemory provides memory and retrieval over documents. See what is Mem0 and what is Supermemory. Evaluate this kind of tool when you are building an app for other people.
• A shared work record: fenbs keeps projects, tasks, Decisions and rules, lessons learned and Where we left off for people and their AI apps to read and update. It fits when continuity depends on the state of the work.

How to start in about five minutes

You do not need to import years of notes to find out whether this helps. Start with one small handoff you can test today. The first version can be a plain document or a project on a shared kanban board.

1. Pick the project you most often re-explain. Give it a clear name and write one sentence about the result you want. Leave your other projects alone for now.
2. Write where you left off, the next three tasks and two or three rules. In plain notes, use those as headings. On fenbs, put the work in tasks, the instructions in Decisions and rules, and the stopping point in Where we left off.
3. Connect the AI apps you use. The integrations guide explains connecting them to fenbs. With plain notes, give the assistant access through your chosen connector, or attach or paste the document if you do not have one.
4. At the end of the session, ask the AI to save where you left off. Review its summary and corrections. With plain notes and no write connection, ask for a short replacement progress note and save it yourself.
5. Next time, ask a different AI to read the rules and progress, then carry on. Give it the same notes if you are using files. If it needs a detail you forgot, add that detail to the record rather than repeating it only in the chat.

Mistakes to avoid

• Saving everything. A huge archive is not a useful starting brief. Save what changes future work and keep source links for the rest.
• Keeping facts without rules. Knowing the project’s background does not tell an assistant what it may do. Write the limits explicitly.
• Keeping the only copy inside one app. Test the handoff to another assistant before you depend on it.
• Hiding what the AI changed. Read updates and keep an edit record, so a mistaken summary does not silently become an agreed fact.
• Never pruning old notes. Replace stale progress, mark superseded decisions and remove duplicate instructions. Preserve the reason when an earlier choice still explains the work.

Where fenbs fits

fenbs is the brain your AIs share: a visible record of the work that stays useful when you change apps or models. Claude, ChatGPT, Cursor, Codex and other AI apps read and update the same projects over MCP. The team can see what every assistant did in History, with each change attributed to the person or named assistant who made it.

People write the rules and every assistant reads them first. Assistants can add notes signed with their name, but cannot decide a decision or pre-approve work. You can watch one AI hand work to another to see how the shared record carries the next session.

If you mainly want a library of reading and research, a notes app may suit you better. If you are building memory into an AI product for customers, evaluate a memory engine. fenbs keeps the work; it does not capture web pages, read your email or search your drive.