Every company already has a knowledge base. It’s scattered across Slack threads, Notion pages nobody kept current, a Google Drive folder called “final_v3,” and a few people’s heads. The information exists. Finding it is the hard part, and the person who knows where it lives is usually heads-down on something else.
At SCHWAI I built Project Brain to close that gap. It runs at brain.schwai.com: a FastAPI backend behind a React frontend, Postgres and Supabase for storage, Redis on the fast path, and a set of background workers that pull company content in and keep it current. One worker ingests books. Others take on the rest of what the company produces and reads.
The reason an enterprise should own this, rather than rent a generic tool, comes down to specificity. A general assistant knows the internet. It doesn’t know your pricing exceptions, why a past deal fell through, or the internal name for the thing three teams argue about. That knowledge is the actual moat, and it should sit somewhere the whole company can query in plain language instead of pinging whoever happened to be there in 2023.
The part that makes it worth building is the feedback loop.
A knowledge base that ships once and then rots is worse than useless, because people trust it right up until it burns them, then stop trusting it entirely. So the design goal was never “index everything once.” It was: every time someone uses it, the system should get a little more current.
Questions people ask reveal what’s missing. Answers people correct become new ground truth. The workers keep pulling in fresh material so the base tracks the company as it actually is this week, not as it was at launch. Live usage is the maintenance mechanism. The tool improves because people lean on it, which is the opposite of how most internal software ages.
On top of that live corpus you stack the models.
The pattern is retrieval first: an open-source model answers, but it answers against the company’s own documents, not its training data. The org’s knowledge is the context; the model is the reader. Open-source matters here because the data is sensitive and the whole thing runs where the company controls it, not inside someone else’s API.
That alone answers most day-to-day questions with real sources attached. Call it the floor.
The ceiling is fine-tuning.
Once you have a running base and a steady stream of real questions, corrections, and preferred answers, you have exactly the material a fine-tune needs. You can teach a model the house style, the vocabulary, the way this specific company reasons about its own work. Retrieval keeps the facts fresh; fine-tuning makes the model fluent in the place it works for.
I want to be honest about where this sits. It’s the direction, and the earlier stages carry most of the weight today. Fine-tuning compounds what retrieval already made possible, and each step is only worth taking once the one before it is solid.
The payoff is efficiency that’s hard to see on any single day and obvious over a quarter. People stop re-asking answered questions. New hires ramp against the same source everyone else uses. Decisions get made against what’s actually true instead of what someone half-remembers.
I think most enterprises end up here, whether they plan to or not.
The knowledge is already the valuable part of the company. Right now it leaks out through turnover and decays through neglect. An internal knowledge base that gets more current the more it’s used, with the company’s own models reading the company’s own corpus, turns that liability into something that compounds.
Project Brain is one company’s version of it. The shape generalizes — so much that I’ve been building an open-source take on the same idea: Selvage, a local-first hybrid-search layer over the same kind of scattered sources — Slack, wikis, code, and databases — queryable by people and agents alike.