How to Build the Knowledge Base Your AI Agents Can Actually Use

You have tried to hand something off before. Maybe to a new hire, maybe to a contractor, maybe to a tool. You wrote instructions, they followed them, and what came back was wrong in a way you could see instantly and couldn't explain quickly. The gap is the same whether the thing receiving the handoff is a person or an agent.

Most firms have some of the first and a little of the second. The criteria are usually the missing piece, and they're what makes anything you delegate come back right.

The gap Deloitte named

Deloitte's 2026 Human Capital Trends research found that 60% of executives now regularly use AI to support their decisions, while only 5% consider themselves to be leading the way on AI and decision-making. As Deloitte puts it, many organizations teach AI how to decide while assuming humans already know how.

Most of them never wrote it down. The criteria that separate a good call from a bad one in a specific business live in the owner's head, pass by osmosis to whoever has been there longest, and stay invisible to everyone else.

Harvard Business Review made the companion argument in June 2026: as AI makes polished work easier to generate, judgment becomes the scarce skill, and most organizations train people to use AI tools rather than to exercise the judgment needed to evaluate what those tools produce. Both findings point at the same missing artifact.

Why a folder of documents isn't a knowledge base

Think of what your business knows in three layers, because the effort you need is different at each one.

Facts. Who the client is, what the scope says, what you charged, what the lead time was, and what the result was for the business. You have these, scattered across systems, and consolidating them is the data work, but the most important can be the feedback loop of the post mortem for all your client engagements.

Procedures. How a project moves from signed to installed. You have more of these in practice than on paper, which is normal. Automations or not, it is worth understanding the steps, down to the kinds of client interactions, so your team is prepared when you go on vacation.

Decision criteria. Why you specified that material over the cheaper one. What makes you walk away from a project. What you check before you trust a new vendor. Which client requests you accommodate, and how you tell the difference.

Give a model facts and procedures and you get something competent and generic. Give it the criteria and you get something that sounds like you decided it, because the reasoning it followed is yours. Your firm's value lives in that third layer, and it's the layer almost nobody writes down.

Which is why "our AI output is generic" and "I can't delegate this" turn out to be the same complaint. Neither a model nor a junior hire can apply criteria nobody has stated.

What to write down

Start with the decisions you repeat, because those are the ones worth the effort.

• The scoping call. What you listen for, what makes you quote at the top of your range, and what makes you decline.
• Specification. The rules you apply that a catalogue won't tell you. Which finishes fail in which conditions. What you have learned the hard way about a supplier's lead times.
• The vendor list, with reasons. Why you use who you use, and the conditions under which you'd use someone else.
• Pricing logic. The conditions that move a number, alongside the number itself.
• Client communication. Not just what you say, but the manner you say things with clients, how you address issues, concerns, and what you’d never say.
• The exceptions. Every rule above has cases where you break it. Those cases are what let a model or a new hire handle a situation the procedure didn't anticipate, and they're the easiest thing to leave out.

Dictating this is faster than writing it, and most owners get further in an afternoon of talking than in a month of intending to document. You already know all of it, and your team should too. The writing down is the missing step.

What stays out, and why the boundary is the discipline

Building this forces a decision most firms have never formally made, which is what an AI system is allowed to see.

Client confidential material stays out. Nonpublic information stays out. Anything privileged stays out. In a professional practice you don't get to skip that boundary, and drawing it is genuinely most of the work, because you go through what you have and decide case by case. When you work with an LLM on an enterprise contract, they will opt-out your information from their general pool of services, but you'd never want one client's financial details mixed with another's as an agent hands information from one step to the next.

Drawing it well is also what makes the library safe to widen later. A context library with no boundary gets locked down the first time somebody notices, and then nobody uses it.

The tooling got cheaper, and the tool is still not the work

Notion's spring 2026 releases moved a lot of this within reach of a small firm. You can configure a Custom Agent against your own playbook and tone, so it answers from your material instead of from the internet. You can call a Worker, Notion's hosted runtime for custom code, to run real code inside the workspace, so an agent does the math on line items and writes a structured result back. You can point an external tool at a database view through the Views API, without scraping or guessing at the schema. You can set rules and let AI Autofill populate properties from them.

So a build that needed two custom integrations, a webhook layer, an external script host, and a developer on retainer in early 2026 can now sit inside one workspace for you.

No platform assigns the owner, writes the criteria, or decides what stays out. You do those three, and they're the ones most firms skip on the way to buying something.

What you can do this week

Take one decision you made in the last few days that a competent outsider would have gotten wrong. A material you rejected, a client request you pushed back on, a vendor you passed over.

Write three sentences: what you chose, what you rejected, and the thing you knew that made the difference.

Do that once a day for a week and you'll have seven of your firm's real operating rules on paper, in your words, ready to hand to the next person or the next system.

All Context Engineering Briefings