Where the idea comes from
The term "second brain" was developed by Tiago Forte as a personal method. He defines it as an external, centralized, digital repository for the things you learn and the resources they come from. His method has four steps: Capture, Organize, Distill, Express. That is: collect, organize by how actionable it is, distill into usable summaries, and turn it into output.
In an organization the challenge is bigger. There are many authors, different permissions, knowledge that goes stale, and above all knowledge that was never written down. Nonaka and colleagues described the difference between tacit knowledge, held in people's heads and experience, and explicit knowledge that can be documented. In their model, an organization learns as knowledge moves back and forth between the two forms. An organizational second brain is mainly a mechanism that helps tacit knowledge become explicit and reach the right people.
What is worth capturing, and what is not
Not everything written in an organization is knowledge. A full export of chats and email mostly creates noise, and sometimes exposes sensitive information. It is better to start with content types that have clear value and are created anyway at fixed points in the work.
Decisions are worth recording together with the context, the alternatives and the reasoning, for example as ADRs. That way whoever comes later understands not only what was decided, but why.
- Architecture and product decisions, with the reasoning and alternatives.
- Incident reviews and what changed as a result.
- Operational procedures (runbooks) and how-to guides.
- Questions that keep coming from customers or new hires, with the approved answer.
- Project context: goal, contacts, open decisions.
A structure that holds up over time
Forte recommends organizing by actionability rather than by topic, in four categories: active projects, ongoing areas of responsibility, resources for future use and an archive. In an organization this works especially well because of the archive: it keeps history, but it can be left out of default search so answers do not rely on old information.
Each item should carry a few fixed fields. Without an owner and an update date, there is no way to know what to trust.
- Owner: who is responsible for the information being correct.
- Last update date and next review date.
- Audience and permissions: who may see it.
- Status: draft, approved or archived.
The smart layer: asking the knowledge
Once the foundation is in order, you can add a RAG layer that answers questions from the content. Three rules separate a useful assistant from a source of errors: every answer points to a source and its date, when no source supports an answer the system says it has none, and every query is filtered by the permissions of the person asking.
Permission filtering has to be built deliberately. The Azure AI Search documentation, for example, describes a pattern in which each document carries the identities or groups allowed to see it, and the filter is applied on every query. When you want to ask questions that connect many documents, such as "which systems were affected by decisions we made this year", a GraphRAG-style knowledge graph may help. Still, start with simple RAG and add a graph only when there is a proven need.
How to start
Pick one team and one area, and collect 30 real questions people ask today in chat or in the hallway. These are the questions the system needs to answer, and they are also how you measure it: was a source found, was the answer correct and was time saved.
Make documentation part of the work rather than an extra task: a decision closes with a short record, an incident closes with a review. Once a quarter, go over items whose review date has passed. Before adding personal or sensitive information, check the privacy and security obligations that apply to you.