Enterprise AI Myth #2: A Local Knowledge Base Means Your Knowledge Is Captured

Start with the original knowledge manager

The most famous "knowledge base manager" in Chinese history may be Confucius. He compiled and taught the Six Classics — the knowledge foundation of a civilisation. But what shows how he actually used knowledge is the Analects: facing a specific person with a specific problem, organising knowledge on the spot and generating an answer.

In today’s terms: the Six Classics were his knowledge base, a student’s question was the prompt, and Confucius understood the asker, judged the situation, assembled context and generated an answer for that moment. The Analects is the log of that system running, again and again, on real problems.

A knowledge base does not get smarter by itself. Knowledge only earns value when it flows into real situations. Still water goes stale.

Files reached the server; knowledge never reached the work

When an owner brings up "knowledge base", I ask three questions first: does every meeting produce minutes? Does anyone keep project status current? When a contract gains an addendum, does it automatically attach to the same client and project? If the answers are no, that local server will soon gather dust — remember the wave of all-in-one LLM appliances a couple of years back?

Building the 2Brain knowledge product two years ago taught me something uncomfortable: AI massively increased knowledge production. Someone who never wrote minutes can now generate three thousand words in ten minutes. It used to be that nobody wrote. Now AI writes too much, and nobody reads.

• Three walls: nobody builds, nobody uses, nobody maintains. Faster generation does not remove them — it raises the cost of verifying, iterating and aligning all that content.
• The real misconceptionhas little to do with on-premise versus cloud. A company’s most valuable information today is the stock level that just changed in the ERP, the client who just went cold in the CRM, a service call recording, a site photo, an equipment alarm.
• Those are not yet knowledge: only when the stock change maps to an order, the complaint maps to a product, and the alarm finds its owner and past handling records do scattered facts become business context you can judge and act on.

Most knowledge bases only hold what was already written down

What actually runs a business is the stream of facts that keep happening and changing — and the relationships between them. Palantir calls this layer the Ontology: clients, orders, contracts, equipment and staff defined as business objects; objects carry relationships; relationships carry rules; rules trigger actions — a living model of how the business actually runs.

That used to be extremely expensive. Agent frameworks like OpenClaw have collapsed the cost of calling different systems, reading multiple modalities and assembling context per task. But no framework understands your company out of thin air: who the client is, which project an order belongs to, who may see what, what an exception should trigger — someone still has to define the semantics. The ontology answers "what things are and how they relate"; the agent framework answers "for this task, what to pull and what to do next". Connect the two layers and knowledge starts to flow.

The pilot numbers from a construction client

Company A’s invoices all arrive by email as PDFs. Finance identified supplier, invoice number, amount, GST, project, PO and approver by hand. The client initially wanted two things: store the PDFs in a searchable knowledge base, and use OCR to cut typing. We did not build the library first — we wired invoice email, PDF recognition, project rules, approval nodes and payment status into one workflow.

• Pilot numbers: one round of 377 live records ran at 95.49% first-pass accuracy; in another round of 407 candidate invoices, true OCR failures numbered just 12 (2.9%).
• The real blockers were elsewhere: 173 invoices hit incomplete rules; 132 hit missing supplier mappings, POs or required fields. AI misreads: under 3%. Unclear rules and data: over 70%.
• What the client finally saw was itself: which rules had never been written down, which base data was missing limbs, which responsibility chain never closed. Ten local servers cannot store that — it only surfaces when the process actually runs.

Why knowledge never flowed before

Legacy enterprise software assumed one system per data type, one scenario per problem. But a real piece of business rarely lives in one system. A client complains about a faulty batch: the contract holds acceptance criteria, the ERP holds batch and shipping records, the site team has photos, the service recording holds the client’s account, the workshop video may hold the operation itself. Bringing all of that into a single judgment used to cost more than anyone would pay.

The biggest change from multimodal AI is that bridges are finally being built between the islands: one task can now read the contract, scan the table, understand the photo and listen to the call. But reading many modalities only gives AI senses. Recognising that they all describe the same client, the same order, the same failure — that is what real business understanding means.

Three fundamental questions

First: does it know what happened today? AI is most dangerous not when it hallucinates, but when it cites a policy that expired — in perfect structure and a professional tone. Every answer inside a company should carry time: based on which version? Data current to when?

Second: can it recognise one complete event? Upload a contract and it answers payment terms beautifully. But the project manager’s real question is: should this payment be chased today? Was acceptance signed, was the invoice issued, did the money land in the ERP? Only when information from different systems and modalities is aligned to clients, projects, orders, equipment and owners does knowledge grow a skeleton.

Third: can it push things forward? For a New Zealand mortgage brokerage (Company B), we made the first minute of every lead count: an enquiry arrives on WeChat — first home, NZD 890k budget, auction this week, only 15% deposit. The system identifies source and urgency, flags the risks, deduplicates against records, routes to the right adviser by the firm’s own playbook, and attaches the next actions. The adviser opens a client card they can act on immediately. Answer leads to judgment, judgment to task, task to a named owner — that is pushing forward: information → judgment → task → action → result → feedback.

Company knowledge forms after the results come back

A retail e-commerce client (Company C) reconciled accounts with Excel and manual labour. We drew hard boundaries for phase one: no changes to core systems, nothing auto-sent to clients, no touching approvals, no ERP rebuild — just two commands: one generates our standard statement, one matches the client’s returned sheet and outputs a discrepancy list.

The decisive move was the last step: every round’s handled exceptions crystallise into rules — how fields map, how amount differences attribute, how returns offset, which issues go to sales for confirmation. Phase one alone produced ten stable exception types; once stable, the next round reuses the rules and skips fresh manual judgment. Judgments repeatedly verified by business results are what company assets actually look like.

On-premise solves ownership and security; the flow closes the loop

None of this argues against local deployment. Contracts, R&D files, drawings, client records — that data should be in the company’s own hands, some of it never leaving the intranet. On-premise answers: where data lives, who controls it, what may leave, whether access can be audited. Build that — with interfaces reserved for your internal systems.

Whether knowledge flows is a different layer: can information scattered across local servers, SaaS tools, business databases and edge devices work together when a task happens? For SMEs, do not imitate Palantir’s AIP and ontology abstractions — that sword may be too heavy to swing. Keep data where it already lives, replace nothing; across dozens of client deployments we have never built a new SaaS and forced staff into it. The real work is aligning content to the right client, project, order and event — building connection, identity, permissions, relationships, memory and long-term context — then handing you a rule set you can maintain.

Many owners picture company knowledge as a warehouse: the more you store, the smarter you get. I prefer a river: a warehouse only cares whether things checked in; a river cares where the water comes from, where it flows, whether it jams, and whether it returns to the system. What survives round after round of flowing — that deserves to be called an asset.