How to Build a Corporate Second Brain in a Weekend

Part six of The Corporate Second Brain, a six-part series. The full map is at the end.

Five posts of theory earn one post of doing. If the corporate second brain is an architecture and not a product, then you should be able to stand up a real first version yourself, this weekend, without a vendor call or a budget request. You can. Here is the build I would set up for a company on a Saturday.

No vector database. No six-figure platform. A folder, a config file, and three habits.

Saturday morning: the folder

Make one directory. Inside it, four things.

A sources folder. This is the record. Drop in the real documents, the ten to thirty that a new executive would need to run the business. Contracts, the current pricing, the org chart, the policies that actually get referenced. The AI reads from here and is never allowed to change these. They are the truth.

A pages folder. This is where the AI writes plain-language summaries, one page per topic, with links between related pages. You do not fill this in by hand. The assistant builds it from the sources over time. Think of it as the wiki your company never got around to writing.

An index file. One page that lists every topic with a one-line description. This is the table of contents the AI reads first to figure out where to look.

A log file. An append-only list of what came in and when. One line per addition, with the date at the front so plain text search can find it. This is your history and your freshness record in one place.

Put the whole thing under version control. That single step gives you the audit trail, the change history, and the "who edited what" record for free. You are already ahead of most enterprise deployments.

Saturday afternoon: the config file

This is the most important file in the whole system, and it is just instructions written in plain English for the AI to read before it does anything.

It says how your company works. What the sources folder is and that it is read-only. How to write a page and how to link it. What "current" means and how to flag something that looks stale. Which folders it is never allowed to open. The tone to use. The rule that every claim has to point back to a source.

To make it concrete, a few of the actual lines I would write, in plain English:

• Treat everything in sources as read-only. Never edit a source. If a source is wrong, write a note on the topic page, do not touch the original.
• Every claim on a page must link to the source file it came from. No source, do not write the claim.
• If two sources disagree, flag it on the page instead of picking a winner. A human resolves it.
• Never read from the folders named in the "off limits" list, even if asked.
• When a source is more than twelve months old, mark the page as needs-review.

That is not code. It is house rules a careful new hire could follow, written down once so the machine follows them every time. Spend the afternoon here. This file is what turns a generic chatbot into a disciplined maintainer of your knowledge. Get it right and the assistant behaves like a careful librarian. Skip it and you have a clever intern with no instructions and access to everything.

Sunday: the three habits

The build is easy. The habits are what make it last. There are three.

Ingest. New document shows up, it goes in the sources folder and gets a line in the log. That is the whole ritual. Make it a two-minute reflex, not a project.

Compile. Point the AI at the new material and have it update the summary pages and the links. It reads the raw source once, writes down what matters, and connects it to what is already there. You review what it wrote. This is where the knowledge actually gets organized.

Lint. On a schedule, have the assistant check its own work. Look for two pages that contradict each other. Flag claims that have gone stale. Find pages nothing links to anymore. This is the janitorial pass that keeps a knowledge base from rotting, and it is the step everyone skips.

Ingest, compile, lint. That loop is the entire operating discipline. It is boring on purpose. Boring is what survives contact with a busy quarter.

What to do Monday

You will have a working second brain by Sunday night. Monday is about proving it earns a place.

1. Ask it the questions your team actually asks. The real ones, the ones that currently cost someone twenty minutes of digging. See if the folder answers them.
2. Check every answer's source. Click through. If it cannot point to the document, that is a gap in your sources, not a reason to quit.
3. Give it to one more person. Watch where it breaks for someone who did not build it. That is your roadmap.
4. Only then talk tools. If plain text and a folder genuinely stop keeping up, now you know exactly which problem to shop for, instead of buying a platform on faith.

The reason I push people to build the cheap version first is not thrift. It is that you learn what you actually need by using something real, and almost nobody needs what they were about to buy. Start with the folder. Run the loop for a month. Then, and only then, decide whether you have outgrown it. Most companies have not.

That is the series. Six parts, one argument: a second brain is an architecture you build, not a product you buy, and the cheapest legible version beats the expensive opaque one for most companies. If you are just arriving, start at part one and read the case from the top.

---

The Corporate Second Brain, a six-part series

1. Your Company Already Has a Second Brain
2. RBAC Is the Hard Part of AI
3. Why Ingestion Is the Whole Ballgame
4. I Replaced the Vector Database with a Folder
5. From What We Know to What You Should Do
6. Build a Corporate Second Brain in a Weekend (this post)