An AI second brain is a structured, always-current knowledge base that an AI reads before it does any work, so every agent, tool, and teammate answers from the same source of truth instead of guessing. For a business, that brain is the context you already have, scattered across your site, your docs, your calls, and your head. Get it into one place an AI can navigate, and everything downstream, from a chatbot to a full agent workflow, gets sharply better.
This piece is the written companion to a conversation I had with Ryan Doser on his AI Rabbit Holes series, where I walked through my exact AI second brain setup and why "second brain as a service" is one of the more underrated AI business ideas right now. The full interview is embedded above. Below is the method, written down.
The short version: build the knowledge base before you build the agents, keep it in a portable format you own, and feed it with a simple flywheel: ingest what the business produces, synthesize it into durable notes, archive the raw source. Do that well and the second brain becomes the most valuable asset in the stack.
Why the second brain comes before the agents
Most people start with the agent. They wire up a multi-step workflow, point it at a vague prompt, and wonder why the output sounds generic. The problem is almost never the agent. It is that the agent has no idea who the business is. An agent with no context is just a confident stranger.
Flip the order. The first thing to build is the knowledge base, the second brain. Once the context exists in a form the AI can read, the agents on top of it get easy, because they stop inventing facts and start retrieving them. Context is step one. Automation is step two, and it only pays off because step one is solid.
Do not build it on one AI ecosystem
The single biggest mistake I see is people pouring their business knowledge into whatever chat product they happen to use, then treating that product's memory as the brain. When you do that, your most valuable asset is locked inside someone else's tool, in a format you cannot export, subject to their pricing and their roadmap.
Keep the brain portable. I build mine on plain markdown files. Markdown is human-readable, version-controllable, and every model on the market can read it. If a better model ships next month, I point it at the same files and keep moving. The knowledge outlives the tool, which is the entire point of owning it.
The context your business is already sitting on
People assume building a second brain means months of documentation work. It usually does not, because the raw material already exists. Your website copy, your sales calls, your onboarding docs, your best emails, the way you answer the same five questions every week: that is the brain, undigested. The job is not to invent context. It is to capture what is already there and give it structure.
The flywheel: ingest, synthesize, archive
The engine that keeps a second brain useful is a loop, not a one-time import. I run three moves:
- Ingest. Pull in the raw material as it is produced: a transcript, a doc, a page, a note.
- Synthesize. Distill it into a durable note that states the fact or decision cleanly, in the business's own language, so the next read is fast and unambiguous.
- Archive. Keep the raw source, but move it out of the way. The synthesized note is what the AI reads first, and the archive is there when you need to trace a claim back to where it came from.
Run that loop consistently and the brain compounds. Every call, every launch, every decision makes it a little smarter, instead of drifting out of date the way a static brand document does.
Do you need Obsidian, RAG, or a vector database?
This is where people over-engineer. You do not need a vector database to start, and you do not need a retrieval pipeline. For a focused business brain, a well-organized set of markdown files the model reads directly, often called putting it "in context," beats a half-tuned RAG setup, because the model sees the whole picture instead of a few retrieved fragments.
My own setup is deliberately boring: markdown files for the knowledge itself, a tool like Obsidian for navigating them as a human, and a custom app I built on Supabase when a project needs a real database and a client-facing layer. Reach for the vector database when the corpus is genuinely too large to fit in context. Until then, keep it simple and let the model read the notes. If you want to run that setup yourself, the Claude Code + Obsidian second brain guide walks through it step by step, including when an Obsidian MCP server is worth adding.