The business knowledge base: evidence, risks, and how to build one

Every AI system a business runs, a website chatbot, a document engine, an assistant that drafts replies, has the same thing underneath it: a body of knowledge the system is allowed to trust. Get that layer right and the AI answers from what your business actually knows. Get it wrong and you have a confident generator of plausible fiction wired to your name.

Over the past eighteen months that layer has acquired a boom of its own. “Second brain”, “AI memory”, “knowledge base”: the labels vary but the promise is the same. Perfect recall across everything the business has ever captured; walking into every client meeting with a brief that reads like one experienced practitioner handing off to another, generated from files nobody had time to reread. The promise is real enough to take seriously. But the boom has outrun the evidence, and it has shipped with security and privacy problems the enthusiastic write-ups mostly skip.

This is the full picture as we read it: what a business knowledge base actually is, what the measurements say it delivers, where the real risks sit, and how we build them so the risks stay handled.

What is a business knowledge base?

A business knowledge base is a curated, maintained body of what your business knows, structured so an AI system can retrieve from it when it answers, with explicit rules about what to trust. It is not a pile of documents. A pile of documents in a vector database is storage; a knowledge layer is a scoped corpus the system has been told to trust, with rules about which sources outrank which when they conflict. It is one of the six functions of a working AI system, and the one every other function leans on.

The pattern most people now picture arrived in early 2026. Andrej Karpathy’s gist of 4 April 2026 named it: a folder of markdown files an AI agent reads, writes, and maintains. It passed 5,000 stars and forks within three months, and Google formalised the same idea as a draft Open Knowledge Format on 12 June 2026. A hyperscaler moving to standardise a three-month-old pattern is a real signal. It is a signal of momentum, not of proof, which brings us to the first honest question.

Does an AI knowledge base actually save time?

Nobody has measured it properly yet, and the best honest self-tracking in the field says the answer is roughly a wash. That finding comes from Brian Buntz at R&D World (11 June 2026), one month into disciplined use, maintaining roughly 760 pages under citation-required schema rules and lint gates. His verdict: “the time I spend maintaining the wiki and the time it saves me are roughly a wash.” The payoff, he found, concentrated on narrow topics the open web covers poorly.

The field’s one controlled experiment is sharper. The archcheck project ran an A/B test in July 2026 on an agent-built wiki over a codebase and found it saved nothing over letting the agent search the source directly, because the wiki pages were larger than the files they described. Its author’s conclusion is the best design principle the field has produced: token saving “appears only when a page aggregates facts scattered across many files (compression ratio > 1)”, and pages that mirror small source files “are pure maintenance debt”. Either the knowledge base earns its keep through compression, or it should not exist.

Set that against the marketing. Jeremy Utley’s “Teammate Stack” (two Substack posts, 12 May and 16 June 2026) packages the same pattern as eight persona files loaded into a chat assistant; the mechanics are sound, but the “11.5x smarter” claim attached to it carries no cited methodology anywhere it is written. A widely cited survey (Vibehackers, 4 March 2026) reports that most of the 27 public AI memory-system builds it examined were abandoned within weeks; its methodology could not be independently verified when we checked, so we repeat it as the article’s own stated finding. As of mid 2026, no independent, controlled measurement of aggregate time saved by this kind of knowledge base exists, by any organisation. Multiplier claims travel further than the measurement behind them because there usually is no measurement behind them.

None of this makes the pattern a bad idea. It means the time-saved claim is the one to verify yourself, on your own work, before it becomes the reason for the project. Pilot one workflow, measure your own before-and-after, and treat “roughly a wash” as the honest floor rather than an outlier.

If the notes are not the asset, what is?

The durable asset in a business knowledge base is the judgement encoded in its rules, not the notes the AI produces. Hand an agent the same folder of raw material twice, once with a careful instruction file and once without, and you get two different knowledge bases from identical inputs. Karpathy’s own architecture makes this explicit: raw sources, the wiki the agent writes, and a schema document (typically a file called CLAUDE.md or AGENTS.md) that is, in his words, “what makes the LLM a disciplined wiki maintainer rather than a generic chatbot”.

Kenneth Reitz’s essay of 6 March 2026 shows what that file looks like in mature use: a vault of 467 files governed by a roughly 200-line CLAUDE.md he frames as an “API contract” with the agent, whose most valuable section is a list of prohibitions: “Do not create new files unless explicitly asked… Do not restructure existing folder hierarchies.” The negative space does as much work as anything the agent is told to produce.

The wiki pages are, by comparison, replaceable. Delete them and the same agent under the same instruction file regenerates something close to the same wiki. Degrade the instruction file and everything drifts: Karpathy’s comment thread through June 2026 records an unconstrained agent generating “company, Company, Business, and Organization” as four different entities across runs, because nothing pinned the vocabulary down. The instruction file is the one artefact in the system that is genuinely the operator’s intellectual property: a specific person’s decisions, in writing, about what counts as a trusted source, what structure the knowledge takes, and what must never be touched without asking. Spend the careful hours there, not on organising the first batch of notes, and keep that file with the person who runs the business.

Is an AI knowledge base a security risk?

Yes, and it should be designed as an attack surface, because that is what it is. An agent that reads and writes your business’s knowledge combines three things Simon Willison calls the “lethal trifecta”: private data, exposure to untrusted content, and an outbound channel. Put all three in one system and it can be induced to leak what it holds. A knowledge base built from clipped web pages, pasted emails, and forwarded documents is untrusted content by definition.

This has been demonstrated, not theorised. Within 48 hours of Anthropic’s Cowork (a desktop agent with folder access) launching in research preview in January 2026, the security firm PromptArmor demonstrated a working attack: a Word document containing invisible one-point white text that caused the agent to exfiltrate financial documents. The clearest numbers come from OpenClaw, the open-source agent framework whose memory is plain markdown files. In its early-2026 security crisis, SecurityScorecard research reported by Infosecurity Magazine on 9 February 2026 found 40,214 exposed instances across 28,663 unique IP addresses, 63 per cent of observed deployments vulnerable, and 12,812 exploitable by remote code execution. The detail that matters most for this pattern: marketplace skills wrote persistent backdoor instructions directly into the memory files, and those instructions survived after the skill itself was removed. The memory file was the payload. A poisoned note is not bad data sitting in a folder; it is an instruction the agent may act on the next time it reads the file.

The mitigations with real evidence behind them are not exotic. Read-only defaults, so the agent cannot write without deliberate permission. A human gate on anything moving from raw capture into the trusted, reviewed layer. Version control as a rollback mechanism, so a bad write can be undone rather than just discovered. Secrets never stored in notes. And anything ingested from outside the business treated as untrusted until a person has reviewed it, not the moment it lands in the folder. A knowledge base with unattended write access and no gate between capture and trusted knowledge is the one part of a build we treat as non-negotiable.

What happens to client data in a cloud AI memory?

Whatever a vendor’s deletion policy says, data the vendor holds sits under the vendor’s legal exposure, and that is the fact a professional practice has to plan around. In NYT v. OpenAI, a court order issued in May 2025 required OpenAI to preserve output logs it would otherwise have deleted, including chats users had deleted themselves; the blanket order ended on 26 September 2025, but the data it covered remains under legal hold. Retention terms shift too: Anthropic’s consumer terms changed in August and September 2025, moving consumer plans to opt-out training with five-year retention for users who allow it. Commercial and API terms were excluded, which matters, but a policy in force at signup is not a guarantee about next year. Zero-retention arrangements are real, but they are enterprise contract terms, not default architecture.

The honest complication is that “just go local” is not yet a complete answer. The best independent evaluation we have found (a 30-day, six-stack study of local models published in May 2026) puts a floor under private AI: reliable tool-calling starts around 27 to 32 billion parameters, and a supervised local agent handles capture, summarisation, and note updates about as well as a frontier cloud model on short tasks. Long-horizon work past roughly five to eight steps, and the judgement work of curating the trusted layer, remain frontier-model territory, and most practitioners running these systems in 2026 still route through cloud models. The posture that follows from the evidence is hybrid: local processing for the continuous capture of the most sensitive material, frontier models for the judgement work, and the most sensitive files excluded from cloud sessions by design rather than by policy promise. That is the principle behind ConfideAI, our product for mental health practitioners, which de-identifies session content on the practitioner’s own device before anything reaches a cloud model. None of this is legal advice; it is what has actually happened, so a practice can ask its own adviser sharper questions.

How do we build one that holds up?

We build the same knowledge base to face two directions, with a hard boundary between them. Externally, we ground the public chatbot in the public website and nothing else. Your website is the one body of knowledge your business has already cleared for release, so the knowledge boundary and the privacy boundary become the same line, and the same plainly written pages earn citations when AI search engines answer “who does this in Perth”. We run our own site this way, and the full argument is in your website is your AI knowledge base.

Internally, the same discipline applies to the material you would never publish: a scoped corpus the system is told to trust, an instruction file carrying the owner’s judgement, a human gate between raw capture and reviewed knowledge, version control underneath, and client-sensitive material handled on the hybrid terms above. That is where the perfect-recall payoff lives, the pre-meeting brief drawn from every prior interaction, and it is worth pursuing with the measurement discipline this field has so far skipped: pilot, measure, and let compression justify every page. Getting a whole team working against that shared corpus is its own adoption problem, covered in your team has AI licences, you don’t have an AI system.

That evidence base, all of it, is why our Business knowledge base service is shaped the way it is: grounded external answers, gated internal knowledge, and no multiplier claims we cannot show you the working for. If you want to talk through what a knowledge base would actually do for your business, start with a conversation.