Second brain for business: building a secure RAG knowledge system with Outline, Claude, and MCP

Source: Precedence Research, Shivani Zoting

Abstract

The report puts the retrieval augmented generation market at 1.85 billion dollars in 2025 and 67.42 billion in 2034, a compound annual growth rate of 49 percent, with document retrieval as the leading function, cloud as the leading deployment and on-premises as the fastest grower in regulated sectors. Its restraints section names the integration of retrievers, language models and vector stores as the main barrier to adoption, and GPUs, vector databases and low-latency backends as the main cost. We took it as the occasion to document our own setup with Kishan Chamman, our CTO, who built it.

What we mean by a second brain

A second brain for business is a shared, persistent record of how a company works and what it has learned: decisions, documents, meeting notes, playbooks and past projects, kept in a form a language model can search and reason over. Anyone in the organization asks a question through Claude Code or Claude and gets an answer grounded in the company's own knowledge. The second half of that definition matters as much as the first. Once the knowledge is reachable, the model can write applications against it: a pricing calculator, an onboarding checklist, a proposal drafter, a resource planning tool, each built for one company or one person. Ten years ago nobody could justify a software project for an audience of one. Now we build them as a matter of course, and the question has moved to handling the company's data with care while doing so.

How ours is built

It grew out of a proof of concept we could tear down. We built the first version as a greenfield second brain for a sister company, and the Eli5 system inherited that foundation and its lessons. The proof of concept phase involved starting over several times so the system would stop feeding on old, wrong data, which meant everything had to be something we could spin up and destroy outside our production infrastructure. Some elements in the blueprint exist because of that history, and we would build a few of them differently for a client. The only standard it was built to is that it works for us.

1. A person decides what is worth keeping. An agent knows nothing about a company until it is fed. The first layer is the sources: our documentation, our way of working, our branding, our existing codebases and the infrastructure behind them, alongside Slack, Google Drive, meeting notes, historical proposals and financials. Reading is unrestricted, so an agent consults any of these whenever a task needs it, and a feed such as a Slack channel digest or a meeting-notes folder could run unattended. What does not happen unattended is the decision that something belongs in the base, and where. Today a person triggers every ingestion and the agent drafts the change proposal. Nothing is scheduled, because a scheduled feed produces volume and the value sits in the selection. The counterexample is a dump of Slack conversations and years of client PDFs with no instruction on how the base should work, and that would never work for anyone. If we ever automate a feed, it lands as a draft behind the same gate as everything else.

2. A human confirms before any write. Agents infer and propose, and a person approves before anything is stored in Outline as true. The whole loop depends on nobody skipping this step. The gate itself is procedural. The connection authenticates as an administrator with write access to every collection, and the restriction to specific collections lives in the skill instructions and the base prompt, which open with the question whether this change is wanted and allowed. An agent can be talked past it. Doing so makes no sense for a company that wants the best output for the least effort, and we know that a procedural gate is a weaker guarantee than a technical one.

3. Order first, discover before search. Everything in Outline is organized in collections per subject type. Company, commercial and brand information sit in the summary tier, one concise document per subject. Client work, finance and operations sit in the depth tier, where a subject gets a dedicated sub-collection when the material warrants it. Every label carries a stable two-digit number. Every collection opens with an index document, and the index is the only reason the structure works: an agent reads the index, finds the subject that matches the prompt, and looks in one specific area. Each collection also carries its own write rule. Commercial information is agent-writable, meaning drafts followed by confirmation. Brand information is approval-gated, an additional approval before anything changes. Every document carries a provenance stamp with source, author and date, and a change note at the top saying what changed, when, why and by whom. That note is the first thing a model reads on the page. Readers who know the PARA method from our review of Meta's second brain will recognize parts of this, and the questions at the end of this article spell out where the two overlap and where they differ.

We run no vector database and no embeddings. Kishan's statement on camera is the sentence this article exists for. An embedding is a long list of numbers that stands for the meaning of a piece of text, so that two passages about the same thing end up with similar numbers. A vector database stores those lists and, given a question, returns the passages whose numbers sit closest to it. That is the machinery most retrieval augmented generation systems use to find relevant material in a pile of unstructured documents, and sales of that machinery are what the market report adds up. The system works today without any of it because the data is structured for our needs, and every agent has to adhere to that structure. The unstructured dump from step one is the case where that stops being true, and embeddings would be the only way to find anything in it. With the structure in place, discovery replaces search. Finding an index and walking down through it is work, and it is less work than inferring from a prompt which of ten thousand chunks are similar to it. The other counterexample is one big file holding everything: the knowledge would all be in there and none of it would be usable.

4. One access layer, three entry points. Outline ships with a built-in server for the Model Context Protocol (MCP), the open standard for connecting tools to language models, and it authenticates against user accounts. Outline itself runs on our single sign-on. That combination decided the choice. Nobody has a separate Outline account, access is granted and revoked where it already is for everything else, and every person authenticated at Eli5 reaches the knowledge base from any entry point. Claude Code covers development and command line work, Claude chat covers research and drafting, and Claude Design reads the visual material in the same base to produce documents and architecture visuals. The browser surfaces reach the server over HTTPS, the command line uses a local transport, and all of it stays inside the self-hosted boundary.

5. Skills bind what is stable and read what is volatile. Skills live in three homes. Personal skills stay local. Company-wide skills, the way we think a thing should be done at Eli5, live in Outline. Project-specific skills, such as rewriting content for one website under our guidelines, deploying or refactoring, live in Git with the project, and they still carry the company context. A registry in Outline records where each skill lives. The design decision underneath is what a skill embeds and what it reads at runtime: stable facts are bound into the skill, volatile facts are read from Outline when the skill runs. The template for this article series is one example. Every draft reads it live, so a rule changed on Tuesday applies to the article written on Wednesday.

6. Feedback closes the loop. Every interaction feeds back into Outline: what we changed, why we changed it, and where the information we were given was wrong. Documentation normally decays because keeping it current is manual work nobody schedules. Here, saying during the work that a process moved from system A to system B, or that the way we do something changed last month, becomes the update itself, with the rationale and the log of why attached. After several months Outline holds a long change log and a set of archived documents, each archived with the reason our process moved on. When a person edits Outline directly, the agent notices, because it keeps its own edit log and can see that something changed after its last edit, and it asks why. The loop is self-healing on one condition, which is that nobody skips the approval.

What it does day to day

Company facts pulls live from the collections. Asked to share shortly what it knows about Eli5, Claude invokes a skill that reads the company collection, the numbered company profile and the brand and messaging framework, and answers from there, with nothing pasted in beforehand. The same skill is instructed to withhold restricted information, because the neighboring collections hold financials, personal information about the team and proposals, and it sets that boundary itself in the answer.

Proposal prep starts with an assessment. Tenders arrive as packages of documents to be read next to normal work, and most of the hours used to go into finding out whether a tender was worth bidding on at all. The skill assesses fit first, with a rationale, then reads the sources, which for a tender are the tender documents and for a request for proposal also the meeting notes, transcripts and summaries, and builds a dossier per assessment in Outline. It writes under the house rules, the we-form, no marketing jargon and concrete numbers, and submits the assessment for us to read. When it filters a tender out it says why, for example because the buyer wants a party to purchase and manage software licenses on its behalf, which we do not do, and we can override with the reason in front of us. It also checks Outline as the source of truth on every run and reports where the skill has drifted, then waits for approval before anything changes. Our read after six to eight months is that it has never been completely wrong, and that the time spent on a proposal has at least halved. Both are impressions and neither is a measurement. The careful version is that we still do the work and make it our own, and what disappeared is the sifting.

Brand rules turns plain content into an Eli5 document. The brand skill is a living document in Outline with attachments for design tokens, spacing, typefaces, colors and logos, a precedence rule for when a tender prescribes its own styling and that styling wins, and a short list of things we never do, including emoji and stock imagery. It changed how proposals get made. The old way was everyone writing their text blocks in Figma, a design tool with no history of text edits, where one person reverting their own change could undo a colleague's. Now content is written and versioned in Outline, where every edit has a name and a version, and marked as a draft submission when final, which gates further edits. The proposal skill then hands that content to Figma through Figma's MCP server and applies the spacing, fonts, margins and page-break rules from the brand guidelines. Any document we feed it can become an Eli5 document, and nobody has to think about styling while writing. The final document still goes through Figma even though Claude Design could produce it, because small styling edits are easier there and because Claude Design produces HTML and CSS that has to be printed, which does not always translate one to one.

Hallucination is handled in passes. The gates, the skills and the human in the loop do most of it. For text there is one more mechanism: content moves through several passes that have no context of each other, a first pass, a second and sometimes a third to clean up, in the way a video encoder makes multiple passes over the same material.

The link to software modernization

Our rule of thumb in every talk we give is that preparation and infrastructure are eighty percent of the work and the visible AI is the remaining twenty. This system is that rule made concrete. What we built is a way of making company data reachable in a form that is useful to an agent, and reachable alone is worth little. In our review of Meta's AI second brain the lesson was that years of infrastructure work made a viral internal tool possible. Our version of that work took months, which is what a small landscape costs, and it was still most of the project.

For an organization running legacy systems the sequence is the same and the proportions are worse. The knowledge that matters sits in applications that were never designed to be read by anything other than their own screens, in data with undocumented business logic, and in processes nobody wrote down. A second brain reads only what is in order. Connecting the existing applications, exposing their data through interfaces an agent can call, and documenting the processes around them is modernization work under another name, and it is the same work the forward deployed engineers now placed inside enterprises end up doing. The 6R framework applies system by system, because a system that only needs to be readable is a different case from one that needs replacing.

Concluding remarks

The report sizes a market for components and never asks whether a buyer's knowledge is in a state to be retrieved. Our own answer to that question took a wiki, a numbering convention, an index at every root and one MCP server. The report adds up sales of vector databases, embedding pipelines and GPUs to arrive at its 67 billion dollars, and our system would not register in that market, because it contains none of them. The work is in putting the knowledge in order before any tool touches it, and there is no shortcut. On camera Kishan called it doing the legwork, and that is what it took.

This setup has limits. Two people administer it, and at the scale Meta reported, tens of thousands of users, the roles, permissions and gates would have to look different. We have not built that. The approval gate is a rule agents follow, and a determined user could steer an agent past it. And the loop that keeps the base honest depends on a person reading and approving every change, which is exactly the step that gets skipped when things are busy.

Two moves are worth avoiding. Buying a vector database before writing an index is the first, because structure is what makes discovery possible and retrieval machinery cannot supply it afterwards. Letting agents write to the knowledge base on their own is the second, because a base that updates itself without approval propagates its own mistakes.

Questions we kept coming back to

Do we need a vector database? Not at our size and with our structure, and we tested this directly. Every collection has an index, every label has a stable number, and an agent reaches the right document by reading indexes and descending. Embeddings become necessary when the material is unstructured, a Slack archive or a decade of PDFs, and the fix for unstructured material is to structure it first.

Are we locked into one AI vendor? The models and the harnesses are interchangeable, and we have run the same skills and knowledge base through a different harness with other models with similar results. We use Claude because our developers already work in Claude Code, because Claude Design has no equivalent elsewhere, and because chat, code and design cover the whole workflow from one ecosystem. The knowledge base and the skills would survive a switch.

We are not technical enough to self-host. What then? Notion offers a comparable model with its own AI built in, so the MCP server and the harness are handled by the vendor. The structure remains the organization's own work: the collections, the indexes, the numbering and the write rules have to exist whatever tool holds them. We chose Outline because it runs on our single sign-on, because self-hosting let us tear down and restart during the proof of concept without juggling accounts, and because it is easy for a person to edit by hand.

How do we stop wrong information from spreading through the base? Three mechanisms keep it in check. Nothing is stored as true without a person approving it. Every change carries a note at the top of the page with what changed, when, why and by whom, and that note is the first thing a model reads. And when a person edits a page directly, the agent sees that something changed after its own last edit and asks why, so the base and the agent stay in agreement.

Can an agent change our logo? Technically yes, and in practice it does not. Brand assets are gated: the skill opens by asking whether the change is wanted and allowed, and the guidelines say it is not. The argument is economic. The organization wants the best output for the least effort, and working around a rule that protects the brand costs effort and produces worse output.

Do we use the PARA method that Meta used? Partly, and one level lower than Meta did. PARA stands for projects, areas, resources and archives, Tiago Forte's split of all personal information into short-term active work, long-term responsibilities, reference material and everything no longer active but worth keeping. Meta organized its second brain on it. PARA was not our starting point. The top level of our base is split by subject type and by write rule, because who may change something decided the collections. The PARA split shows up in the numbering inside each collection. The 00 slot is the index. The areas, the ongoing responsibilities, are the low-numbered summary documents that rarely move: company profile, brand framework, standard answers. Projects are the numbered sub-collections in the depth tier, one per proposal, tender or event, each with its own index. Resources are the reference collections: use cases, engineer profiles and the boilerplate we reuse. Archives take the 99 slot in every collection, so they sort last, stay readable and carry the reason they were archived. The reading pattern is what Meta called progressive disclosure. The agent starts at the index and descends only where the task requires, and the numbering tells it which documents are current, which are reference and which are history before it opens any of them.

Where to start

Everything described above depends on knowledge that is in order, and for most organizations the first deliverable is knowing what runs, where the data lives and which processes were never written down. Our modernization assessment maps the application landscape, scores each system on how reachable its data is, and produces the sequence: what has to be made readable, what has to be connected, and what has to be replaced before any agent can be trusted with it.

Full video episode

The first step to start the modernization journey

Software modernization and architectural rebuilds lie at the heart of Eli5. We solve complexity to deliver direct business value by focusing on pragmatic, cloud-native transitions.

Before deciding whether to wrap the legacy system, buy a new SaaS product, or use AI to build custom tools, total visibility into the current tech landscape is essential.

A free brainstorm to discuss the legacy stack is available to book. It is the essential first step to turning technical debt into a scalable, modular future.