Company brains / 23 Jun 2026

How to query a company knowledge base, and keep it honest

Once you have let a model compile your company knowledge into a wiki, two things become possible that were not possible before. You can ask it hard questions and get researched answers. And you can ask it to audit itself.

The first one is the obvious payoff. The second one is the part most people never reach, and it is where the real compounding happens.

Asking the hard questions

A static help centre answers the questions you already wrote down. A compiled wiki can answer the questions you did not.

Karpathy makes a point here that surprised me. He expected to need a heavy retrieval system to query a knowledge base this size. He did not. At the scale of a few hundred articles, the model maintaining its own index and short summaries was enough. You ask a complex question, the agent reads the index, pulls the handful of articles that matter, and works out the answer from them.

So the questions you can now ask change shape.

Not "what is our returns policy", but "which products generate the most returns, and what do the reasons have in common".
Not "what did this supplier quote", but "which suppliers have quietly raised prices this year and by how much".
Not "what did we decide", but "why did we stop doing the thing we used to do, and is that reason still true".

These are questions that used to need a person to sit down for an afternoon and pull threads from six places. Against a compiled wiki, they are a sentence.

Render the answer, then file it back

There is a small habit here that turns querying from a lookup into a flywheel.

When you ask a real question, do not let the answer disappear into a chat window. Have the model write it as a clean note. A markdown summary, a one-page brief, a simple chart. Then file that note back into the wiki.

Now the next person who asks a related question does not start from the raw pile. They start from the answer you already worked out. Karpathy describes his own explorations always "adding up" for this reason. Every query you run leaves the knowledge base slightly richer than it found it.

The part people miss: linting the knowledge

This is the move I had not seen before Karpathy spelled it out, and it is the most useful one.

You can run the model over the whole wiki as a health check. Not to answer a question, but to inspect the knowledge itself. Treat your company brain the way a careful engineer treats a codebase, and lint it.

A good linting pass looks for:

Contradictions. Two documents that describe the same policy two different ways. The model finds them and shows you both, so a human can decide which is right.
Gaps. Concepts the wiki refers to but never explains. Questions a customer would obviously ask that nothing answers.
Stale facts. Rates, prices and procedures that look old, or that a quick web search suggests have moved.
Missing connections. Two articles that clearly belong together and were never linked, which often point at a new article worth writing.

The model does not fix these silently. It surfaces them. A person decides. But the work of finding them, the tedious read-the-whole-thing-and-cross-check work, is done for you. Karpathy notes that the model is also good at the next move: suggesting the questions you should be asking but have not.

Keep the human on the edits

The same discipline I apply to every agent applies here. The model can find the contradiction. It should not get to decide the resolution and quietly rewrite the truth.

Read-only by default. The linting pass produces a list of things for a human to look at. Which rate is current, which policy is the real one, which gap is worth filling. The model drafts, a person approves, and only then does the corrected fact go back into the raw pile. The brain stays trustworthy because a person still owns what counts as true.

Prompt you can use

I want you to run a health check over my company knowledge base and tell me where it disagrees with itself or falls short. Do not change anything. Just report.

Go through the material I give you and produce a short report with five sections:
1. Contradictions: places where two sources describe the same thing differently. Show me both, and where each came from.
2. Gaps: concepts that are referred to but never explained, and obvious questions a customer or new hire would ask that nothing here answers.
3. Stale facts: rates, prices, dates or procedures that look out of date. Flag them; do not guess the new value.
4. Missing links: articles that clearly belong together and would make a useful new article if combined.
5. Questions I should be asking: things this knowledge base hints at but does not resolve, that I would benefit from looking into.

End with the three fixes you would prioritise first, and why.

The rule

A knowledge base is not finished when it is written. It is finished, and re-finished, every time you query it and every time you audit it.

Ask it the questions a person used to need an afternoon for. File the answers back in so the next person starts ahead. Then point the model at the whole thing and ask where it is wrong. The brain that audits itself is the only kind that stays worth trusting.