Does a 'Second Brain' Work for a Company? What the Research Says About Obsidian as Shared Memory

The “second brain” has been a personal-productivity idea for a decade. The interesting question in 2026 is not whether it works for one motivated knowledge worker (it does) but whether it survives contact with a whole company: many editors, conflicting versions, staff turnover, and now AI systems that need to read the same knowledge. This piece looks at what the research and the data say, where the method holds up, and where it quietly falls apart.

The data: what scattered knowledge actually costs

Start with the problem the second brain is supposed to solve. The numbers are larger than most teams assume.

McKinsey’s widely cited research found that employees spend an average of 1.8 hours every day, roughly 9.3 hours a week, searching for and gathering information. That is close to a quarter of the workweek. McKinsey’s own framing is blunt: it is as if a business hires five employees but only four show up, while the fifth spends the day hunting for answers and contributing nothing.

The cost is not only time. When the answer is hard to find, people do one of three things: they recreate work that already exists, they ask a colleague (consuming two people’s time instead of one), or they guess. In a company without a reliable shared memory, the same decisions get re-litigated, the same questions get re-answered, and institutional knowledge walks out the door every time someone leaves.

A company second brain is, at its core, an attempt to make the organization’s knowledge findable, by people and, increasingly, by machines.

What “second brain” means, and what changes at company scale

The term comes from Tiago Forte’s “Building a Second Brain” method: capture what matters, organize it so you can find it later, distill it, and put it to use. For an individual, the payoff is obvious, you stop holding everything in working memory.

Scaling that from one brain to an organization changes the problem in three ways the personal-productivity literature rarely addresses:

1. Many editors, one truth. A personal vault has one author who remembers their own conventions. A company vault has dozens of contributors who do not. Without a deliberate structure, it degrades into the same mess it was meant to replace.
2. Knowledge has to outlive people. The point of organizational memory is that it survives turnover. That raises the bar from “notes I understand” to “notes a new hire (or a new system) can understand cold.”
3. Two kinds of reader. This is the genuinely new part. In 2026, the people reading the knowledge base are no longer only people. AI agents increasingly retrieve from it too, which puts a premium on structure that both a human and a machine can navigate.

That third point is why the tooling conversation has shifted, and why a fifteen-year-old note-taking app keeps coming up.

Why Obsidian keeps showing up in the research

Obsidian is a note-taking app built on a deceptively simple foundation: your notes are plain-markdown files stored locally, linked together like a wiki. There is no proprietary database and no required subscription. That design has three properties that matter for a company knowledge base.

• You own the files. The vault is a folder of text files you can back up, version-control, and move anywhere. There is no platform to be locked into and nothing to export if you switch tools.
• It is human-readable and machine-readable at once. Because the storage format is plain text rather than a proprietary database, both a person and a program can open, read, and edit the exact same file. A knowledge base, the collection of documents a system retrieves from, is most useful when it is not trapped behind an API.
• Links carry meaning. Notes reference each other the way a researcher cross-references sources, so context can be followed rather than dumped all at once.

None of this makes Obsidian the only valid choice. Notion and Confluence are excellent for human-only documentation. The reason Obsidian dominates the second brain literature specifically is that its plain-text, you-own-it model ages well, and, as it turns out, suits the way AI systems prefer to read.

The 2026 shift: from human notes to machine-readable memory

Here is the development that moved this topic from productivity blogs into engineering discussions. In April 2026, Andrej Karpathy (a founding member of OpenAI and former head of AI at Tesla) published a short blueprint he called an “LLM wiki”: a knowledge base built as interconnected markdown files an AI maintains and reads, with Obsidian as the visualization layer. No vector database, no conventional retrieval-augmented generation (RAG) pipeline.

The claim that got attention: on small, focused knowledge bases, this markdown-first approach can cut token usage by up to 95% compared with naive document loading, while being far simpler to run. Karpathy’s analogy was that RAG “recompiles” the sources on every request, whereas a structured wiki is more like running the compiled program directly, the knowledge has already been organized into a form the model can use.

The practical reading for a business is not “RAG is dead.” It is that for the size of knowledge base most companies actually have, policies, procedures, FAQs, product specs, a few hundred documents, a well-structured, linked markdown vault can be cheaper, simpler, and more transparent than the heavyweight retrieval stack that vendors often reach for first. An AI agent pulls the relevant notes into its context window, grounds its answer in those sources, and, when wired through something like the Model Context Protocol, can even write new knowledge back.

That is the version of “second brain” that did not exist when the term was coined: one that an AI workforce reads from and contributes to, not just a tidier place for humans to keep notes.

How a team can start (the honest DIY version)

The method is more important than the tool. A small team can begin without hiring anyone:

1. Inventory where knowledge actually lives. Usually it is spread across email, chat, a half-dead wiki, and a couple of shared drives. List the sources before touching the vault.
2. Design a taxonomy first, files second. Decide how knowledge is organized (by function, client, process, policy) before you import anything. Structure imposed afterward never sticks.
3. Write atomic, linked notes. One idea per note, linked to related notes. Resist the urge to paste in 200 PDFs and hope search sorts it out. It will not. Curate.
4. Assign an owner. A knowledge base without a maintainer goes stale within weeks. Someone has to own hygiene, pruning, updating, resolving conflicts.
5. Only then connect AI. Once the vault is clean and structured, an agent can retrieve from it reliably. Connecting an AI to a messy vault just produces confident wrong answers faster.

If your team is small, your knowledge is modest, and someone enjoys this kind of work, doing it yourself is entirely reasonable, and a good way to learn what your knowledge actually contains.

Where the method breaks

The research is honest about the limits, and so should anyone selling the idea be.

• Scale. The markdown-wiki approach shines from roughly ten to a few hundred documents. Past that, managing the web of interlinks gets expensive in tokens and effort, and a vector-search layer starts to earn its keep. The right answer for a large unstructured archive is often both, not markdown alone.
• Discipline. The single biggest failure mode is neglect. A vault is only as good as its maintenance, and maintenance is unglamorous, recurring work that quietly stops happening when everyone is busy.
• The cold-start problem. Turning scattered, contradictory, half-documented company knowledge into clean atomic notes is genuine editorial labor. It is the part teams consistently underestimate, and the part that determines whether any of it works.
• Governance once AI can write. When agents start writing back into the vault, you need rules for what they may add and where, or the brain fills with low-quality machine notes. That governance does not design itself.

None of these are reasons not to do it. They are reasons to be clear-eyed about the work involved.

The verdict

The second brain idea does scale from a person to a company (the data on lost knowledge makes the case on its own) but it stops being a note-taking habit and becomes an infrastructure decision. The 2026 twist is that a company’s knowledge base is now read by both humans and AI agents, which rewards plain-text, owned, well-linked systems like Obsidian and penalizes knowledge locked inside proprietary tools.

For a small team with the time and the inclination, building it yourself is a worthwhile project. The harder cases, a few hundred messy documents, multiple departments, agents that need to read and write reliably, and nobody whose job is to keep it all clean, are where most teams stall. If that is the situation you recognize, we do this as a done-for-you engagement: building a company knowledge layer in Obsidian that your AI agents read from and feed back into. Either way, the principle holds: get the knowledge right first, because every AI agent you deploy afterward is only as good as what it can retrieve. For the build-side view of that, see our guide on how to train an AI agent and the 3-tier AI workforce model.

FAQ

---

Christos Papadimitriou is the founder of theagency47, where we build AI agents and the knowledge layer they run on. Sources for this article: McKinsey’s research on time spent searching for information, and Andrej Karpathy’s April 2026 “LLM wiki” knowledge-base pattern.

---

Key terms in this post: knowledge base (RAG) · RAG · context window · MCP · AI agent