Company second brain: from wiki to skills, it’s all about context8 min read

I’ve been thinking a lot about all the hype surrounding “second brain”. I discussed this with others in the field and my colleagues who are either building a second brain or have a version of it.

For those unfamiliar, the second brain movement started with the “Wiki” idea by Andrej Karpathy: organizing the agent’s personal knowledge in a sort of an interlinked Wiki structure of local MD files. This later expanded to organizing personal data in a much wider format, with users often using Obsidian to organize and visualize notes and adding data from meetings (Granola/Whisperflow/Zoom transcriptions) into the Wiki.

As that “Wiki” expanded, it became obvious that there’s some real value to sharing the information in it. Thus the “company second brain” projects started blossoming. The Utopic version of a second brain is having everything possible transcribed: zoom call, F2F meetings, even casual interactions, emails, slack messages, documents – all into a huge data database like Snowflake. Imagine that anyone in the company can ask this Snowflake instance anything they want and instantly have every question answered.

Whoops, not a good idea. First, this is super expensive. The amount of data that goes into something like this is just crazy and retrieving data from it becomes extremely difficult, slow and costly. Security and data segregation become an issue. How do you prevent a 1:1 personal data, financial data, management decisions, HR data or even decisions to terminate someone from slipping into the transcripts and being accessible. Not everyone should know everything…

Also, who needs this, what does it save us and is this even a good idea?

I would say in general, a contained version of this is a good idea. Much of the reason that middle management exists is to float issues upstream and clarify decisions downstream. Much of this can now be done with a second brain.

Second brain for technical teams

A technical second brain can be much easier to maintain. Many companies just use a Dropbox/Google drive/OneDrive directory that holds shared knowledge that Claude / Codex can share. Automation for pushing this to a Git repo is quite simple, or you can really use Github to manage this as well (I guess it’s a very small effort for OpenAI/Anthropic to support this scenario without having to install custom skills to manage this type of thing). The source of truth now becomes the Github repo and the local copies are local git repos.

This can add knowledge and capabilities like shared skills, shared decisions, architectural designs, visual designs (design system decisions, for example) and various other company product decisions.

Small teams don’t really need much beyond just a simple sync around the repo, but larger companies with numerous larger teams will run into severe limitations very quickly. The most severe issues involve context poisoning where a particular user might make local decisions that conflict with the second brain data, either introducing conflicting data or overriding company decisions inadvertently (in some cases maybe intentionally?).

Keeping it in git and merging can be done using a dedicated agent that looks for conflicts and can alert a user if their changes are conflicting, resolve conflicts and merge the results.

Note that this is not a good method for maintaining project documentation. For that, the better way is to include the wiki as an integral part of the project itself. It’s pretty easy to create. You just set aside a coding agent and ask it to go over the project, document it thoroughly into a docs folder, split by architecture, gotchas, product decisions, technical decisions, and other things that it concludes might be helpful in small containable md files. The key is to tell it to make sure that the code and readme.md all point to the documents directory to ensure it is referenced everywhere and considered a part of the project and not an external resource. The key piece for the agent to know is that the intent here is to allow a quick onboarding of another agent to the project to avoid pitfalls, potholes and technical sinkholes…

Once it’s integrated in the repo project structure itself, the coding agent will maintain it as if it was code. It will read it as if it was part of the code and if something changes, it will adapt or modify the documentation (remember those “documentation is the code being easy to read and clear” or “documentation becomes stale the minute it leaves your keyboard” – trust the AI to maintain these, so they are not true anymore).

Second brain for product, marketing and non-technical teams

This type of second brain can be really cool for technical teams, but doing the same thing for non technical teams will be extremely difficult.

Take a team of lawyers for example, they have very specific knowledge sets and it spans across email, slack, word files and other documents. The same applies to bookkeepers, sales, customer success, etc. They each have their own second brain knowledge.

On top of this, management probably wants data to bubble up (unfiltered via middle management) and the team might need info that the management generated. How to produce a scalable knowledge graph that is secured and separated?

There are a few approaches that could make things easier, at least until the big boys solve this problem, hopefully in an open manner, but more likely through an expensive closed solution.

1. Personal second brain – each person that wants this, can transcribe their own meetings and maintain their own second brain. Obsidian is quite useful for this, any agent can basically sort and clean it up. Use the REM sleep mechanism to optimize it – an agent should wake up at night, identify all the information it collected during the day, find any information that is critical and important to keep for the future and organize it in an easily retrievable way in folders and MD files. This means that if you talked to a particular customer, that customer will have a md file updated reflecting information that is important to remember about them, what you’re working on together, etc. Same goes for projects. There will be overlap: overlap is good – it’s ok that the information about a particular project lives both in the file of the person you talked to, the company and the project files. Let the agent manage this for you. When you have questions, make this your primary data source for your agent. You can expose your agent to your email/conversations/etc. – just make sure not to transcribe things you don’t want documented (let’s not make this a reality show or a soap).

2. Team level second brain – a second layer of data includes data that is either in the personal second brain that the agent is 100% sure is relevant to the entire team or data that originated in team level meetings that are, by their nature, team based. An agent can also collect data for this second brain from your team slack channels – it shouldn’t be in your 1:1 channels or zoom calls. Once it retrieves the data, an agent can organize it in real time or nightly and point out inconsistencies where decisions were overturned, or don’t correspond to personal or management decisions. Those should be highlighted and alerted to the person making the incompatible decision so they can make their choices in an informed manner.

3. Management level second brain – this is basically a team level second brain but because of the sensitivity of the data and decisions being made, it should be handled in a much more nuanced manner. Only final decisions and public data should be shared here to avoid potential leaks into the rest of the company. It might be a good idea for a human to go over some of the data, at least at the beginning, to ensure data security. It’s also a good idea to leave the management brain out of the company second brain.

4. Company wide second brain – this is the toughest one and should hold only data that is concrete, informational that could be relevant to the entire company. Reported Financial results only, for example, information about personnel (who holds what position).

This leaves a lot of data out, including sentiment data, for example, that management wants to hear from the entire team. This can be gathered separately or harvested from slack and other sources. It’s not a good idea to harvest this type of data directly from the company brain.

So, what are you looking for in a second brain or a company brain, did you have any attempts at building one and what were your conclusions?