A head of AI at a private equity fund asked us a question recently that most vendors dodge: "Is this a knowledge management problem, or a structured enterprise data problem?"
It is the sharpest question you can ask about any "AI brain" product, because the two problems need completely different machinery, and a vendor who will not pick one is quietly promising to be mediocre at both.
Our answer: it is the first one, on purpose. This post is the full reasoning, and then the machinery: how the thing is actually built, because if you are evaluating anything in this category, the detail is where the claims either hold up or fall apart.
The two problems, pulled apart
A structured data problem looks like this: your transactions live in Xero, your positions in a portfolio system, your pipeline in a CRM, and the numbers disagree. Fixing it means target data models, deduplication, a warehouse, a semantic layer. It is real work, it is valuable, and it has an established industry.
A knowledge problem looks completely different: why did we pass on that deal in 2023? What are our actual investment criteria, not the ones on the website? Who introduced us to that founder, and what happened last time we worked with them? What did we decide in the last quarterly review, and what has changed since?
None of those answers live in a warehouse. They live in meeting notes, email threads, someone's memory, and a Slack channel nobody scrolls back through. That is the material an AI agent actually needs before it can do useful work for you, and it is the material almost no company has in a machine-readable form.
A warehouse holds your numbers. A knowledge layer holds what the numbers mean here: the criteria, the decisions, the relationships, the rules. Agents need the second before the first is any use to them.
Why we refuse to solve both
When we build a company AI brain, we deliberately do not touch the structured side. We do not model your transactional data, dedupe your CRM, or build a semantic layer over your warehouse. Your quantitative data stays in the systems built for it, and agents reach that data directly through those systems' own APIs when a task needs figures.
That is not a limitation we apologise for. It is the design.
The moment a knowledge product starts duplicating quantitative data, you get a second copy of the truth that is wrong by lunchtime. The brain holds the layer above: what things mean, what the rules are, what has been decided. When an agent needs this quarter's revenue, it asks the accounting system, not a stale copy.
And when a company's real problem is master data cleaning or warehouse modelling, we say so and point them at that kind of engagement instead. Selling a knowledge layer to a data-quality problem is how AI projects end up in the 60 per cent that Gartner says get abandoned.
What a knowledge layer actually looks like
Evaluators coming from enterprise data usually ask about three things by name: taxonomy, ontology, knowledge graph. Fair questions, and the answer should be concrete, not hand-waving. Ours is implemented in plain markdown and git rather than a proprietary graph store, and the structure is real and enforced.
A real taxonomy. Every brain has explicit top-level domains (identity, clients, operations, people, systems), defined in a routing document the ingest pipeline reads. New knowledge is filed by deterministic rules first: most items match an existing page or a clear location and are placed with no AI involved at all. Only genuinely ambiguous items escalate to an AI judge, and that judge is constrained to the existing category list. It cannot invent new categories at 2am.
Entities with known aliases. People, companies and funds are canonical pages. When a new fact arrives about an entity under one of its alternative names, it lands on the right page, not on a new orphan. A deterministic identity guard stops two entities that merely look similar from ever being merged, and brand-new people or organisations enter only through a proposal a human approves. The model is never allowed to mint a person.
Typed pages. Every page declares what it is: a meeting note, a person, a client, a process, a point-in-time signal. The type is load-bearing, not decoration. Point-in-time fragments are allowed to accumulate and be consolidated; curated pages may never be rewritten by automation. That one rule is the difference between a system that tidies itself and a system that slowly eats your best content. Relationships are typed too: newer facts supersede older ones with the lineage kept, and open conflicts are marked as contradictions rather than silently resolved.
A real graph. Pages are densely linked, backlinks are first-class, and every domain keeps a maintained index so the root of the vault reaches everything in about two hops. Because it is all plain text under version control, the whole graph is human-auditable and every change is a revertible commit with an author.
Governed writes. New knowledge does not silently appear. Routine updates land automatically once the system has earned trust, but anything sensitive or structural waits in a review inbox for a human's approval, and a sensitivity screen flags anything carrying personal information. When a technical evaluator asks "what stops the AI writing rubbish into our source of truth?", the honest answer has to be "a human, by default".
How answers come back out
Storage is half the job. The other half is retrieval that deserves trust.
When you ask the brain a question, it runs hybrid search: keyword matching and vector search fused together, re-scored, with well-connected pages boosted by their backlinks. Then trust ranking sits on top: curated pages outrank raw fragments, recent outranks stale, and anything a human has flagged as wrong or contradicted is pushed down until the flag is resolved. The answer is synthesised from the ranked pages with the sources attached, so "where did that come from?" always has an answer.
And where the brain does not have the answer, the correct behaviour is to say so. A sourced "we do not have this" beats a fluent guess every single time, because the fluent guess is the one that ends up in an investment memo.
The part everyone skips: maintenance
Here is the uncomfortable truth about every knowledge base ever built: they do not fail on day one. They fail on day 180, when the links have rotted, the duplicates have piled up, and two pages quietly contradict each other. At that point people stop trusting it, stop contributing to it, and the wiki becomes a graveyard.
So the machinery we are proudest of is the least glamorous. Every night, an automated doctor repairs broken links, rebuilds the indexes, and surfaces orphans and contradictions. Every week, a consolidation pass merges the accumulated fragments into clean canonical pages: entity-guarded, one revertible commit per merge, so any bad merge can be undone in seconds. And when anyone flags an answer as wrong, the source page loses ranking influence immediately, not at the next rebuild, and stays flagged until a human resolves it.
A knowledge layer that does not maintain itself is just a wiki with better marketing.
The failure mode we caught in our own pipeline
One more thing, because honesty about failure is what makes the rest credible.
While stress-testing our own build pipeline, we ran an unguided pass with a cheap model over thin source material and watched it fabricate a plausible investment rubric. Confident, well-formatted, wrong. Exactly the output that would sail through a demo and detonate six months later.
That test reshaped the product. The seed build now runs on a source-authority brief: we catalogue which of your sources are authoritative for which topics before anything is written, and high-stakes material (investment criteria, anything an agent will act on) is synthesised on a stronger model and traced back to its sources. Where the evidence is thin, the correct output is a marked gap that says "we do not have this yet", never a confident invention. Where sources disagree, the conflict is surfaced for a human to resolve, never silently averaged.
If a vendor tells you their AI knowledge product has no failure modes, they have not looked for them.
The infrastructure is deliberately boring
The last thing a technical evaluator usually asks is what gets spun up. The answer: almost nothing, and that is a feature.
A company's instance is two containers on one small server (or a box in their own cloud account): a Python engine exposing MCP and a JSON API, and a web UI behind Google SSO for browsing, asking, the graph view, the health report and the governance inbox. The vault itself is a git repository of markdown files. The search index is derived from those files and rebuildable at any time, so there is no database server, no queue, no warehouse. Backups are a git push. The scheduled work (hourly collection, nightly doctor, weekly consolidation) is plain cron. Roughly 450 automated tests cover the engine, the ingest resolver and the governance paths.
Two properties fall out of that design. First, zero lock-in by construction: the knowledge is plain text the client owns and can walk away with, and because agents connect over MCP, the same brain feeds Claude, GPT, Gemini or whatever is best next month. Second, speed: an instance is typically running the same day access is granted. The real timeline driver on a build is getting access to the sources, not the infrastructure.
How to evaluate anything in this category
Whatever you buy, from us or anyone else, ask these five:
- Which problem does it solve? Knowledge or structured data? A vendor who claims both is doing neither properly.
- Where does the knowledge live, and can you leave with it? If the answer is a proprietary platform rather than files you own, the exit cost is the product.
- What stops bad writes? Look for human governance on sensitive changes, not just a promise of accuracy.
- What maintains it on day 180? Ask what happens to broken links, duplicates and contradictions, specifically and automatically.
- What happens when it does not know? The right answer is a sourced "we do not have this", not a fluent guess.
If you are working out where a knowledge layer fits in your own AI roadmap, that sequencing question, what to build first and what it should hold, is exactly what our AI Audit exists to answer before you spend real money on anything.
Common questions
What is an AI knowledge layer?
An AI knowledge layer is the single place where a company's decisions, criteria, relationships and context live in a form both humans and AI agents can read and query. It sits above your systems of record (your CRM, accounting, warehouse) and holds the knowledge about them: what things mean, what the rules are, and what has already been decided.
Is an AI knowledge layer the same as a data warehouse?
No. A warehouse holds your quantitative data: transactions, metrics, records. A knowledge layer holds meaning and judgement: why a deal was passed, what the criteria actually are, how decisions get made. Agents consult the knowledge layer first for context, then reach into your systems of record directly when a task needs numbers.
How do you stop an AI knowledge base making things up?
Trace every answer to its source pages, make abstaining the correct behaviour when evidence is thin (a marked gap, not a confident guess), and run a correction loop: when a human flags an answer as wrong, the source page is down-ranked immediately until someone resolves it.
What infrastructure does an AI knowledge layer need?
Very little, if it is designed well. Ours runs as two containers on one small server: an engine exposing MCP and a JSON API, and a web UI. The knowledge itself is plain markdown in a git repository, the search index is derived and rebuildable from the files, and backups are a git push. No database server, no queue, no warehouse.
