Guide · Updated November 8, 2026
How to build an AI second brain for a product team
An AI second brain for a product team is a shared, linked record of your accounts, calls, tickets, requests, decisions and shipped work that every AI tool reads before it answers. Start with Markdown files in one repository, sync each source on a schedule, link everything to the account it came from, and precompute the summaries so everyone gets the same answer.
Same question, asked by two people
“What should we build to make Kestrel Orthopedics happy?”
Product manager asks
Make every first visit 30 minutes.
notes/booking.md
updated 41 days ago
Doesn’t know about Kestrel’s $96k open deal.
Account executive asks
Offer Kestrel a discount to close the deal.
crm-notes/kestrel.md
updated 9 days ago
Doesn’t know about the 40 other clinics with the same problem.
Two answers, each partly right. Neither sees all 41 clinics or the $639k at stake.
What an AI second brain is
A second brain is a set of notes you keep outside your head so you can find and reuse what you’ve learned. Tiago Forte made the phrase popular with his book Building a Second Brain.
The AI version changes who keeps the notes. In April 2026 Andrej Karpathy described an LLM wiki: you drop raw material into a folder, and a model writes and maintains linked Markdown pages about it. Claude Code, Codex or another agent reads those pages before it answers, so it starts from what you already know. Most setups follow his model: three layers, and three jobs the model does.
Three layers
- Raw sources
- Calls, tickets, notes and exports. Kept as they arrived and never edited.
- The wiki
- Linked Markdown pages the model writes from the sources and keeps current.
- The schema
- One instructions file, CLAUDE.md or AGENTS.md, that says how the wiki is organized and maintained.
Three jobs
- Ingest
- Read a new source, update every page it touches, and note it in the log.
- Query
- Answer from the pages and cite them. File a good answer back as a page, so the wiki compounds.
- Lint
- Look for contradictions, stale claims and pages nothing links to.
Two plain files keep it navigable: index.md lists every page, and log.md records every change. Karpathy puts the practical limit at about a hundred sources and a few hundred pages before you need search.
For one product manager this works well. Open-source starters such as PM Brain set it up with a short interview.
What breaks when a team shares it
A product team’s material lives in a CRM, a support desk, call recordings and a tracker, and several people ask questions at once. Each of these has a fix in the steps below.
Two people get two answers.
Each person’s copy and each prompt drift apart, so “What should we build to make account X happy?” gets a different answer depending on who asks.
It goes stale.
Your CRM, tickets, call transcripts and Jira change every hour. The files change when someone remembers to update them.
Answers can’t see the money.
A question about one customer misses the open deal, the renewal date, or the 40 other customers who asked for the same thing.
The AI repeats the same work for every question.
Each question makes the model read and connect the same files again, so answers are slow, expensive and a little different each time.
Nobody settles contradictions.
A model can flag two pages that disagree. A person has to decide which one is right.
A rebuild erases what people fixed.
When the AI rewrites a page from its sources, a correction someone made by hand disappears unless it was recorded as a decision.
How to build the team version in five steps
Each step adds files to one repository. Step through to watch it grow, and open any file to read or copy it.
AGENTS.md
The schema: the rules every AI tool reads first.
# Product brain Read this file before answering any product question. ## Layers - sources/ Raw records, synced on a schedule. Never edit by hand. - accounts/, pods/, maps/ Pages you write and keep current. - AGENTS.md This file: the rules every AI tool follows. ## Where things live - accounts/ One page per customer: ARR, renewal date, open deals, and links to every call, ticket and request. - pods/ One folder per product area: requests.md, decisions.md. - maps/ Summaries rebuilt after each sync: insights, conflicts. - index.md Every page, one line each. Update it when you add one. - log.md What changed and when. Append only, newest last. ## Operations - Ingest: after each sync, file new records into accounts/ and pods/, link them, and add a line to log.md. - Query: answer from maps/ and the pages first, and cite the file. Open sources/ only to check a claim. If an answer took real work, save it as a page and add it to index.md. - Lint: every night, list pages that disagree or have gone stale in maps/conflicts.md and name the pod's owner. Never pick a side. ## Rules - Every fact keeps its source link and date. - Link every request to the account that made it: [[accounts/<name>]]. - Keep hypotheses apart from decisions. Only an owner records one. - Never edit a settled decision. Supersede it with a new entry.Step 1 of 5
AGENTS.md
The schema: the rules every AI tool reads first.
# Product brain
Read this file before answering any product question.
## Layers
- sources/ Raw records, synced on a schedule. Never edit by hand.
- accounts/, pods/, maps/ Pages you write and keep current.
- AGENTS.md This file: the rules every AI tool follows.
## Where things live
- accounts/ One page per customer: ARR, renewal date, open deals,
and links to every call, ticket and request.
- pods/ One folder per product area: requests.md, decisions.md.
- maps/ Summaries rebuilt after each sync: insights, conflicts.
- index.md Every page, one line each. Update it when you add one.
- log.md What changed and when. Append only, newest last.
## Operations
- Ingest: after each sync, file new records into accounts/ and
pods/, link them, and add a line to log.md.
- Query: answer from maps/ and the pages first, and cite the file.
Open sources/ only to check a claim. If an answer took real
work, save it as a page and add it to index.md.
- Lint: every night, list pages that disagree or have gone stale
in maps/conflicts.md and name the pod's owner. Never pick a side.
## Rules
- Every fact keeps its source link and date.
- Link every request to the account that made it: [[accounts/<name>]].
- Keep hypotheses apart from decisions. Only an owner records one.
- Never edit a settled decision. Supersede it with a new entry.
Step 1 of 5
Take the whole repository with you
One prompt holds every file above. Paste it into Claude Code or Codex in an empty repository, and it creates the files and starts following AGENTS.md. Replace the sample account, ticket and call with your own after the first sync.
Sample workspace: online booking software for clinics.
LLM wiki, RAG or a product context layer
All three give an AI tool something to read before it answers. They differ in who keeps that material current.
- RAG
- Searches your documents when you ask and passes the closest passages to the model.
Who keeps it current: Nobody; it reads the raw documents.
Good for: One-off lookups across many documents.
Where it falls short: Connects nothing ahead of time, so every answer rebuilds the picture.
- LLM wiki
- Linked Markdown pages that a model writes from your sources.
Who keeps it current: The model, whenever someone runs it.
Good for: One person’s knowledge, up to a few hundred pages.
Where it falls short: Goes stale and drifts once several people and live sources feed it.
- Product context layer
- A shared record of accounts, evidence, decisions and shipped work, linked and kept current from source systems.
Who keeps it current: Scheduled syncs, plus people who review.
Good for: A product team and the AI agents it works with.
Where it falls short: Needs connected sources and someone who owns decisions.
The product context layer guide covers what that record holds and how it differs from a knowledge graph and MCP.
What a second brain won’t do
- It won’t decide for you.
- It puts the customers, the evidence and the money in front of whoever asks. It surfaces; a person decides.
- It only knows what you connect.
- A source that isn’t synced doesn’t exist for it. If calls live in someone’s inbox, it has never heard them.
- It can link the wrong things.
- Models make mistakes. Keeping every source next to the claim lets a person check before acting on it.
- It doesn’t keep itself private.
- It holds customer names and revenue. Decide which AI tools may read it before you connect them, and keep it out of anything customers can reach.
Build it or buy it
Past a point, syncing, linking and review take more time than the questions do. Describe your team and see which setup fits.
Questions come from , the material lives in , and the answers revenue.
Then
Build the team version
One repository, scheduled syncs, accounts as the key, precomputed maps and an owner for conflicts. Expect the syncing and review to grow with every source you add.
How Zentrik does it
Zentrik does this work for product teams. It connects the sources you choose, such as Gong, Zendesk, Salesforce or HubSpot, and Jira or Linear, links what customers say to their accounts, and keeps the evidence, ideas and decisions in one shared record. Claude Code, Codex, ChatGPT and Cursor read that record through Zentrik’s MCP server, so everyone on the team starts from the same answer. People still review and decide.
Questions
- What is an AI second brain?
- An AI second brain for a product team is a shared, linked record of your accounts, calls, tickets, requests, decisions and shipped work that every AI tool reads before it answers. Start with Markdown files in one repository, sync each source on a schedule, link everything to the account it came from, and precompute the summaries so everyone gets the same answer.
- Can Claude Code be a second brain for a team?
- Claude Code reads an instructions file and a folder of Markdown before it answers, which works well for one person. It can run every step a team needs, too. The team still has to decide where the shared copy lives, what refreshes it from the source systems, and who settles conflicts.
- How is an LLM wiki different from RAG?
- RAG searches your documents when you ask and hands the model the closest passages. An LLM wiki has the model read your sources ahead of time and write linked summary pages, so questions start from those pages. The wiki connects more, and it has to be kept current.
- How do you keep a team second brain up to date?
- Pull from the systems of record on a schedule instead of copying by hand: daily or hourly from your CRM, support desk, call transcripts and tracker. Rebuild the summaries after each sync, and send contradictions to a named owner.
- What should a product team’s second brain contain?
- Accounts and their revenue; every call, ticket and request, linked to its account; the ideas those requests point to; the decisions you made and why; and what you shipped. Each fact keeps its source and date.
- Is Obsidian enough for a team second brain?
- Obsidian is a good way to read and link Markdown, and for one person it is enough. For a team, the hard parts sit outside it: syncing sources, sharing one copy, and deciding which page is right when two disagree.