Grounding AI Agents in an Organization's Knowledge

Most organizations treat an internal AI assistant as a writing project. Clean up the documentation, put it somewhere central, point an agent at it, and good answers should follow. It is a reasonable-sounding plan and it does not work.

A knowledge base can be well written, consistently formatted, and completely current, and the assistant built on top of it can still be confidently wrong. Formatting is not the variable. The variable is grounding: whether the passage the agent retrieves is the passage that answers the question, whether the agent is allowed to see that passage at all, and whether it will say "I don't know" when the passage does not exist — instead of quietly answering from what it already knows about the product you are asking about.

That is engineering work, and it is the part that gets skipped, because it looks like documentation work. This page is the applied companion to The LLM Ladder, which defines retrieval, tools, and MCP as mechanics. Here I am concerned with what you have to do to an organization's own material before any of those mechanics produce an answer someone can act on.

A tidy knowledge base and a confidently wrong answer

Why does our AI assistant give wrong answers?

When people ask that, the cause is almost never that the assistant "doesn't know enough." Usually it is the reverse — it knows too much, from somewhere else.

• The model answered from its own general knowledge of the same product. This is the one that surprised me, and it is the one worth designing against first. The agents I built answered competently, but early on they were too willing to reach past the internal material into adjacent sources: the open internet, or the vendor's own published documentation for the very product being asked about. That material is not wrong. It is correct for the default configuration — and no real environment is the default. The competitor for retrieval is not another document. It is the model's fluent, plausible, entirely reasonable general knowledge of the exact thing you asked about.
• Retrieval returned a neighbour. The correct passage exists, but something adjacent scored higher — a page on the same topic, an older revision, a summary that mentions the right words without containing the right answer.
• Two sources disagreed and nothing said which one was current. The model picked one. It had no way to prefer the live procedure over the superseded one sitting next to it.
• The question was about this environment's exception, and the retrieved document described the general case. The document was not wrong. It just did not cover the situation the person was actually in — so the gap got filled from the general case, which is the first failure again by another route.

None of those are writing problems. Several get *worse* when the documentation gets prettier, because polish makes a stale page look exactly as authoritative as the current one. A knowledge base that reads beautifully to a person can be actively hostile to a retriever — and a knowledge base with a hole in it is worse than one that is visibly incomplete, because the model will fill the hole and never mention that it did.

What grounding actually means

Grounding is the set of decisions that determine which of the organization's own words end up in front of the model at the moment it answers, and what happens when the right words are not there. In practice it is six jobs:

• Shape the source material so retrieval can locate the passage that answers the question.
• Write down what makes this environment different from the default, so retrieval has something capable of beating the model's own general knowledge.
• Scope what the agent may claim, not only what it may see.
• Define when it must refuse or escalate instead of guessing, and where the escalation actually goes.
• Keep the answers true as the organization changes underneath them.
• Read what the agent actually says, on a sample, forever.

The useful reframing is this: retrieval quality is a property of the corpus at least as much as a property of the retriever. You can change vendors, change models, change the index, and inherit the same wrong answers, because the wrongness lives in the source material's shape — or in the parts of the source material that were never written at all.

Shaping knowledge so retrieval works

This is where most of the real work is. A retriever does not read a document; it returns fragments and hands them to a model that will treat whatever it receives as the truth. So the material has to be written to survive being cut into pieces and read out of context.

• One fact in one place. If the same answer exists on three pages, you have not created redundancy — you have created three chances to retrieve the wrong version and no way to tell which one won.
• Chunk boundaries that follow meaning. A retriever slices documents into passages. If a procedure gets cut mid-sequence, it retrieves as half an answer, and half an answer reads exactly like a whole one. Sections should be short enough to be a unit of meaning and complete enough to stand alone.
• Titles and headings that match how people ask. Pages named after internal programs, committees, or project codenames do not get retrieved by someone typing the question in plain language. The heading is retrieval surface, not branding.
• Self-contained passages. "As described above," "see the attached," and "per the previous section" all evaporate the moment a passage is retrieved on its own. Restate the condition instead of pointing at it.
• Conditions stated in the text. If something applies only to one role, one site, or one shift, the passage has to say so in its own words. A qualifier that lives only in a folder name or a page-level tag does not travel with the fragment.
• Contradictions and stale duplicates removed, not archived in place. A superseded page kept "for reference" is not reference material; it is a live wrong answer with a plausible title.
• Dates and ownership inside the page. File metadata rarely makes it into a retrieved passage. If currency matters to the answer, it has to be in the text.
• The exception written down. The largest single source of confidently wrong answers is the gap between the documented general case and the undocumented local practice everyone knows.

None of this is glamorous, and it is most of the project. It is also the part that keeps paying off after the assistant is gone, because what you have actually built is a knowledge base that a *person* can use out of context too.

Document the environment, not just the procedure

The first version of any internal knowledge base is procedures. How to do the task, step by step, in the order an end user does it. That is the material people ask for, so that is what gets written — and once there is a procedure for everything anyone has requested, the corpus looks finished.

It is not finished, and the way you find out is that the assistant starts being confidently wrong about your own systems. Procedures only cover the paths somebody thought to write down. The moment a question falls outside them — a variation, a troubleshooting turn, a "why is it set up this way" — there is no internal record to retrieve, and the model completes the thought from the vendor's public documentation instead. That documentation is about the default configuration. If you never write down what makes your environment different, the model assumes you are standard, and it will say so fluently.

The fix was not more procedures. It was documenting how the environment is actually set up: explanations and diagrams of the real configuration, sitting alongside the step-by-step guides rather than being replaced by them. The distinction worth naming is environment truth versus task steps — and the environment pages are the ones nobody ever requests.

• How the thing is actually configured, described in prose and diagrams rather than as a sequence of clicks.
• What is deliberately enabled and what is deliberately turned off. An absence is invisible to a retriever unless somebody writes it down, and "we don't do that here" is an answer the model will never guess.
• Which defaults were overridden, and to what. This is the highest-leverage category on the list, because it is exactly the set of facts where the vendor's answer and the correct answer diverge. Every override you fail to document is a question the model will answer from the manual.
• How the pieces relate — what depends on what, and what moves when one of them moves.

Writing configuration down feels like a detour from the assistant project. It is the assistant project. And it has a second payoff with nothing to do with AI: these are the pages a new engineer needs and almost never gets. A procedure teaches somebody to perform a task; an environment document teaches them why the task looks like this *here*, which is the whole difference between a person who can follow steps and a person who can troubleshoot. You are writing for the retriever and for the next hire at the same time, and it turns out they want the same document.

Scope and permission are a design decision

The scope rule I ended up with fits in one sentence: the agent may not state a fact unless it can cite the internal record the information came from. No citable internal record, no claim.

That is a tighter boundary than "the agent may read these files," and it is a different kind of boundary — it constrains what comes out rather than what goes in. It is also what shuts down the failure at the top of this page at the moment of answering. The model cannot launder its general knowledge of a product into an answer about your environment if every claim has to arrive attached to an internal source.

The rule was a test result, not a principle

I did not start with that rule, and I did not reason my way to it either. It came out of testing, run on the grounding and evaluation mechanisms built into Copilot itself.

The sequence went: the adjacency problem turned up first, in real answers. Testing was how its shape got characterised — putting real questions to the agent, watching what it actually did with them, and finding the seams where it reached past the internal record into what it already knew about the product. Requiring a citable internal source was the control that reliably stopped it.

That distinction matters more than the rule does. This is an empirical finding about one agent in one environment, not received best practice, and the transferable part is the method rather than the conclusion. If you are building this, the move is not to adopt my rule. It is to test your own agent until you find the control that closes your own leak — which may not be this one.

Use the instrumentation you already have

Worth naming once, because the same instinct shows up twice on this page: the testing above ran on the platform's own grounding and evaluation mechanisms rather than a bespoke harness built for the occasion, and the measurement further down leans on onboarding metrics the organization already kept rather than a dashboard built to show the project in a flattering light.

Reach for the instrumentation the environment already provides before building your own. It is faster to start. It is much harder to accidentally rig in your own favour, because you did not get to choose what it measures. It is already trusted by the people you need to convince, which is most of the argument you were going to have. And it keeps running after you stop paying attention to it. Instrumentation you build to evaluate your own project has the opposite property on every one of those counts, and it usually dies with the project.

Supply side and demand side

Corpus shaping and citation-gating are two halves of one mechanism, and neither works alone.

Shaping the corpus is the supply side: making sure a citable record exists for the things people actually ask. Citation-gating is the demand side: refusing to answer without one. Run the gate over a thin corpus and you get an assistant that declines almost everything and is abandoned within a month. Run a rich corpus with no gate and it will still hand back the vendor's general answer dressed as yours — which is the worse failure, because it is wrong *and* it looks well-supported.

The order matters, and it is uncomfortable. Turning gating on exposes every hole in the corpus at once: the refusals arrive immediately, in volume, and in front of users. That is not the system failing. That is the system enumerating what was never written down, ranked by how often people need it. The refusal log is the work queue, and it is a better one than any documentation audit will produce, because it is sorted by real demand instead of by somebody's guess about it.

Permission is the other half of scope

An agent that can see everything will answer questions it should not. That is not a bug in the model; it is the direct consequence of pointing a retriever at a corpus without deciding what the corpus is for.

• Decide the audience first, then build the agent for that audience. A narrow agent — say, a Copilot agent for IT support questions — is easier to ground, easier to evaluate, and easier to trust than one universal assistant that has to be right about everything.
• Inherit the platform's permissions rather than reimplementing them. In a Microsoft 365 environment, a Copilot agent over a SharePoint knowledge base can respect the access model that already exists. Rebuilding that model beside it creates a second thing to keep in sync, and the two will drift.
• Understand what inherited permissions do and do not say. They describe who may open a file. They do not say whether that file's contents belong inside a synthesized answer, quoted without its surrounding caveats.
• Assume retrieval removes privacy-by-obscurity. Plenty of material is technically readable and practically unfindable. An agent finds it instantly. Anything that was safe only because nobody could locate it is now in scope, and that has to be handled before launch rather than discovered after.

Wrong answers and answers-that-should-not-have-been-given are different failures with different costs. Scoping is how you separate them, and it belongs in the design, not in a follow-up hardening pass.

The most valuable answer is often "I don't know, here is who does"

Refusal is a feature you design, not a failure you tolerate. An assistant that never declines is not well grounded; it is well disguised.

Worth defining explicitly, before launch:

• Out of scope. The question is real but belongs to a domain this agent was never grounded in. Say so and route it.
• Insufficiently grounded. The topic is in scope but nothing retrieved is good enough to answer from. This is the case teams forget, and it is the one that produces the most damage.
• Requires a human decision. Anything with an approval, a safety implication, or a cost attached. The agent can summarize the inputs; it should not render the verdict.
• Time-sensitive. If being out of date makes the answer harmful rather than merely unhelpful, the agent should hand off rather than recite.

Where the refusal goes

A refusal on its own is only half useful, and the other half needs grounding of its own. When the agent cannot answer from cited internal documentation, it falls back to a separate class of material kept for exactly this purpose — vendor contact lists, internal vendor-ownership lists, and basic HR documentation — so that it can still say which vendor, which department, or which person the question belongs to. "I don't know" is a dead end. "I don't know, and this belongs to them" is a resolved request.

Route to the owner of record: a role, a queue, a department, a vendor, or a named person where a named person is genuinely the right answer. The reason a name is safe there and unsafe in a prompt is that ownership lives in maintained data rather than in the agent's instructions. A name written into a prompt is wrong the day somebody changes jobs and nobody thinks to grep the prompt. A name arriving from an ownership list is correct as long as the list is — and the list has other reasons to be kept correct.

Which leads to the part that is not an AI problem at all. You cannot route to an owner nobody designated. Before an agent can direct anyone to a person or a department, ownership has to have been *set*, and in practice a grounding project surfaces every system, process, and vendor relationship for which nobody ever decided who owns it. Those decisions then have to be made — by people, in meetings, with names attached — because the assistant cannot proceed without them.

That is the point I would put to anyone treating this as a technology project. The escalation path is an organizational-data problem wearing a prompt-engineering costume. Building the assistant is what forces the question into the open; answering it is ordinary operations work, and the organization is better run afterwards whether or not the assistant survives.

The economics favour refusal heavily. Users forgive "I don't know, ask them." They do not forgive being wrong about something they then repeated to somebody else. That happens once, and the assistant is finished for that user.

Keeping it true as the organization changes

Knowledge bases rot unevenly, and knowing the order helps you spend review time where it matters.

• Rots first: contact routes and ownership, anything naming a vendor or a product, anything tied to a version or a platform release, and anything written during a project rather than after it.
• Rots slowest: conceptual explanations, policy intent, and the reasoning behind a decision.

What keeps the corpus honest is unremarkable: a named owner per page, a review cadence proportional to how fast that page's category rots, and a change process where updating the document is part of the change rather than a follow-up ticket that never gets picked up.

Retirement matters at least as much as authoring. Deleting or explicitly superseding a page is a grounding action — arguably the highest-leverage one, because it removes a wrong answer from circulation permanently instead of adding a right one that has to compete.

The best decay signal is not a calendar. It is the questions. Sampling what people actually asked, and what the agent actually answered, shows you which parts of the corpus are drifting long before a scheduled review would.

Measuring whether it worked

I built an internal IT knowledge base, self-service documentation, and Microsoft Copilot agents in a 24/7 senior living campus supporting 300+ users. The measured effect was on onboarding: new-hire ramp-up on core systems dropped by an average of two to three days.

Where that figure comes from matters, so here it is plainly. It rests on two things: the HR metrics the organization already kept around employee onboarding, and firsthand experience of that onboarding — I went through it myself when I arrived, saw what it was like, and then took the steps to improve it.

That is not a controlled experiment and I would not present it as one. There was no holdout group, no instrumented before-and-after study, and no attribution model separating the Copilot agents from the documentation work, or either of them from anything else that improved in the same window. What the evidence supports is narrower than a causal claim: onboarding got measurably shorter on a measurement the organization was already keeping, and the person who changed it had an unusually precise idea of what "before" felt like. What it does not support is any statement about which component did the work.

Leaning on the measurement that already existed was a deliberate choice rather than a convenience. A number that HR collects for its own reasons is harder to bend toward the answer you were hoping for, it is already trusted by the people whose opinion you actually need, and it keeps being collected after the project ends — which means the result stays open to being disconfirmed later. Standing up a bespoke dashboard to demonstrate that your own initiative worked is the weaker move, and most of those dashboards do not outlive the initiative that produced them.

Ramp-up earns its place as a proxy for other reasons too. It is felt by managers, and it responds to exactly the thing grounding improves — whether a person can get a correct, specific answer without interrupting someone who already knows.

It is still a proxy, and the limits are worth stating. It is confounded by hiring cohort, staffing levels, and season. It measures time-to-independence, not answer accuracy — an assistant can get someone productive faster while still being wrong at the edges. And it only observes new people; it says nothing about the long tail of experienced staff asking harder questions.

So it is worth watching alongside things that are less flattering and more diagnostic:

• Repeat questions. The same question asked repeatedly is a grounding gap, not a training gap.
• Refusal rate. A rate of zero means the agent is guessing. The number should be visible and non-trivial.
• Escalation follow-through. Whether the routes the agent hands out actually lead somewhere.
• Sampled answer review. Reading real answers is the only measurement that catches confident wrongness, because every other metric looks fine while it is happening.

There is one more thing that figure is evidence of, and it answers a question this page has otherwise skipped: how do you know which documents are missing? I knew because I had recently needed them. I had been the person who could follow every documented step and still not understand why the environment was shaped the way it was — which is the gap that documenting the environment, rather than only the procedure, is meant to close. The proxy measured the fix. Having been on the wrong end of the problem is what located it.

The same problem in public

The internal version of this work is not something I can show you. The public version is. AI Lunchroom publishes its knowledgebase in a form built to be consumed by an agent rather than only read by a person, and you can go check it right now:

• llms.txt — a map of the corpus: every guide as a link with a one-sentence description of what it answers, plus a pointer to the two bulk formats.
• llms-full.txt — every guide concatenated as Markdown, so an assistant can ingest the whole reference set in one request instead of crawling and guessing.
• knowledgebase.json — a structured index carrying, for each page, a title, canonical URL, type, category, description, and its section outline, plus a corpus-level page count and last-updated date. At the time of writing it lists 37 pages.
• An "open in your agent" handoff on the prompt-library pages, which copies the prompt and opens the reader's own assistant.

The interesting part is what the knowledge had to become to be machine-consumable, because it is the same list as above:

• Every page describes itself in one sentence that stands alone, because that sentence is what a retriever ranks.
• Section outlines are exposed in the index, so an agent can see the shape of a guide before deciding to fetch it.
• One canonical URL per guide — no alternate copies competing to be the answer.
• The whole set is generated on every build from the same source as the human-facing pages, so the machine copy structurally cannot drift from what people read.
• Bulk ingestion is offered explicitly rather than left to inference, which removes an entire class of "the agent only found half of it" failure.

Strip out the permissions problem and that is the internal job exactly: shape the material so a machine can find the right passage, keep one canonical copy of every fact, and make the index a build artifact instead of a maintenance chore.

What transfers

If you are standing up an assistant over your own documentation, the short version:

• Budget for corpus work, not formatting work. The retriever's quality ceiling is set by the source material.
• Write down the environment, not only the procedures. Every override you never documented is a question the model will answer out of the vendor's manual.
• Gate on citations: no internal record, no claim. Then expect the refusals, and treat them as the corpus backlog rather than as a defect.
• Test your way to your own control rather than copying mine, and run those tests on the instrumentation the platform already gives you.
• Scope by audience and build the narrow agent first. Universal assistants are the hardest possible starting point.
• Ground the escalation path too, and accept that it will force ownership decisions the organization has been deferring.
• Give every page an owner and review it on a cadence matched to how fast that kind of page rots.
• Delete aggressively. Superseded pages are wrong answers with good formatting.
• Measure with a proxy you already collect, then go read the actual answers, because the proxy will not catch confident wrongness.

The through-line with the rest of my work is the same one in Systems Field Notes: a system only works when the knowledge it depends on is out of somebody's head and into a form the next person — or the next process — can use. An agent just makes the quality of that form measurable, and unforgiving.

For the broader adoption frame, see Practical AI Implementation and the AI implementation checklist. For the operations side of keeping documentation worth grounding against, see Technical Operations and is internal documentation worth it?. If you have a concrete assistant that is confidently wrong and you want it grounded, here is how to work with me.