DEV Community

Cover image for The four parts of a Company Brain
Malik Chohra
Malik Chohra

Posted on Originally published at codemeetai.substack.com

The four parts of a Company Brain

TL;DR

  • A Company Brain is a shared notebook that an AI keeps up to date. It does four jobs. A notes app gives you two of them. You build the other two.
  • The free Second Brain Starter covers the storing and the answering. Collecting and clearing out are yours to add.

I write Code Meet AI, the newsletter where I document how I actually use AI to ship real products, receipts included. New guides land there first.

This is the sixth piece in a chain, from one person's Second Brain to a team's Company Brain. The full list is at the end.

Every time you ask an AI about your documents, it starts from zero. In April 2026 Andrej Karpathy wrote a short file called LLM Wiki about how to stop that.

Karpathy says the AI "is rediscovering knowledge from scratch on every question. There's no accumulation."

His fix is to have the AI write a wiki, a folder of linked notes, as it reads. When a new source arrives, it notes "where new data contradicts old claims." The result is "a persistent, compounding artifact."

You do not write the wiki. You pick the sources and ask the questions.

That works for one person. A company has more people, more sources, and facts that change every week.

So what does a Company Brain actually do all day?

Slite looked inside a dozen of them in September. Slite sells one, so it has a stake in the answer. I use its split because it is the one public source that names all four parts, and I test each part against my own setup. Its finding: every company brain "breaks down into the same four components."

  • Getting signals. What happened today reaches the brain.
  • Remembering. The brain stores it so it can be found again.
  • Dreaming and pruning. The brain tidies up. It merges duplicates and retires old facts.
  • Speaking and searching. People and agents ask it questions.

An agent is an AI tool that does a task on its own, like writing code or drafting an email.

Four stations in a ring: signals come in (a Sentry alert, a Slack message, a call note), get stored as dated facts, pass through a 'dream' step where two facts


1. If it never arrives, the brain never hears

Slite calls this part getting signals. The brain has to hear what happened: calls, chats, error reports, emails. In Karpathy's version, this is you dropping a new source into the folder.

Say Sentry, the tool that reports app crashes, flags that checkout fails on older Android phones. Two people fix it in a Slack thread on Friday: checkout now needs Android 9 or newer. On Monday an agent writes the release notes. It never saw the thread, so the notes say nothing about it.

In my Second Brain. When I save an Instagram reel on my phone, a shortcut adds it to one file, reels-inbox.md. Other notes go into a 06-Dump/ folder. Later a /dump command files each one where it belongs.

30 of the 108 links in the inbox are still marked pending-evidence. That means I have not watched them yet. Collecting is easy. Reading is the work.

Sources on the left with their real icons (Sentry alert, Slack thread, a phone call, an Instagram reel saved from the phone) travel along lines into one inbox f


2. Memory needs a shape

Slite calls this part remembering. You may say your agent can already read the whole folder. It can. That is the problem. Storing and remembering are different jobs. A folder of exported chats is only storage. A fact becomes memory when it sits in a shape you can ask about: one fact, one place, a date on it. Karpathy's shape is a folder of linked text files, one topic per page. I compared how four Claude Code setups store memory in How gstack, Superpowers, claude-mem and ECC handle memory.

Say you export every Slack channel into one folder and ask your agent, "Which database do we use?" It finds forty messages. Half say Firebase and half say Supabase. It cannot tell which half is current.

In my Second Brain. My agent's memory is a folder of 666 short notes. Each note holds one rule or one fact. The file name says what kind it is, like decision_ or feedback_. An index file lists them. The agent reads the index first, then opens only the notes it needs.

So "what did I decide about the price?" has an answer. It lives in a file whose name starts with decision_.

Left, a pile of chat bubbles with 'Firebase' and 'Supabase' mixed, a question mark over the agent


3. Old facts have to leave

Slite calls this part dreaming and pruning. Dreaming is the brain tidying itself: a job that re-reads what was learned that day and re-links it, "the way sleep consolidates memory." Pruning is the other half: "retiring what no longer holds."

Say you raise your price from 49 to 59 euros in June. Both prices now sit in your notes. An agent writing a sales email finds the old one first and quotes 49. You lose 10 euros on every sale.

Amazon built a feature for this. Its AgentCore Memory, in an October 2025 write-up, says the system will "resolve conflicts." The newest fact wins, and the old one stays on file, marked invalid "instead of instantly deleting them." Karpathy's gist has the same idea in one phrase: "noting where new data contradicts old claims."

In my Second Brain. My rule is one line at the top of the vault: never delete a memory or a log, archive it. When a memory stops being true, the file moves to a memory/archive/ folder. There are 18 files in it so far.

A /reorg command is my manual dream. It folds what the daily logs taught me back into the rules, then archives what is finished or replaced. I run it when the vault feels messy. How to build a Second Brain that stays useful is the longer story of keeping a brain current.

In my Second Brain

A tidy brain still answers. Pruning decides whether it answers with this quarter's facts.

The limit. Pruning can lose something true. An old price is wrong for "what do we charge today?" and right for "what did we charge in May?" That is why Amazon keeps the old fact, and why I archive instead of deleting. Slite adds that the few tools that automate this "keep a human in the loop."

So the rule is short: the old fact leaves the answer and stays on file.


4. Agents need a door

Slite calls this part speaking and searching. It is the door. People ask questions in a chat. Agents need the facts delivered to them. Slite puts it this way: "Humans want a conversation. Machines want an endpoint."

An agent can read only so much at once. That limit is its context window, and it is smaller than your whole company. So this part decides what the agent reads first.

Say the record is perfect and lives in a Notion page. A new teammate's agent has no access to Notion, so it reads the code and guesses. The brain knew. Nobody gave the agent a door.

Karpathy's door is simple. He keeps the "LLM agent open on one side and Obsidian open on the other," and asks it questions. (Obsidian is a free notes app.) A team needs the same door for people and for agents.

In my Second Brain. My door for agents is a table in one file, CONTEXT.md. It has six rows. Each row is a kind of task, like content or weekly review, and names the first file to read. An agent starting a content task reads one row and opens one file. It does not load the whole vault and hope.


Each piece answers the question the last one left open

The chain so far:


Which part is missing from yours

A notes app and a chat window already give you remembering and searching. Collecting and tidying up are the two you build yourself. Without them, news arrives by luck and old facts stay until someone gets annoyed.

So here is the one decision for this week:

  • Pick the one of the four that is missing from your setup.
  • Fix that one.
  • Today, open your notes, find one fact that is out of date, and write today's date next to it. Now the next reader can see how old it is.

If you picked remembering or searching, the free Second Brain Starter is a small, one-person start. It has no dreaming or pruning job. If you picked that one, copy my /reorg habit.

This one came from Code Meet AI, the newsletter where I write up the setups I actually run on my own projects.

Top comments (0)