An AI agent is exactly as good as the knowledge it gets. The same model writes a generic proposal when it knows nothing about the client, and a sharp one when it knows what was agreed in the meeting, the price list and how the company writes. That is why rolling out agents in a company starts with a knowledge base, not with picking a model. In this article we show how to build a company knowledge base for AI agents in plain files, what goes into it, how to structure it so an agent reads only what it needs, and how to keep it from going stale. The examples come from the knowledge base we run our own company on.
What a company knowledge base for AI agents is
A company knowledge base for AI agents is an organized set of text files holding what the company knows: about its offer, clients, processes and decisions. Agents and people both read it, and agents write the results of their work back into it. It is structured so that an agent always starts with the current state, then consults the map, and opens the detail only when it needs it.
It is not another app the team has to log into. It is a folder of files you can open in an ordinary editor, read, correct and compare with last week's version. In an agentic system the knowledge base is one of the six elements the team sees, and the one everything else depends on: agents, skills and rules all work on what is in the files. For the full picture of what the system is made of, see what an agentic system is.
Why files and not another system
The first reflex when you hear "knowledge base for AI" is vector search (RAG) or a new tool with a dashboard. Both have their place, but in a small or mid-sized service business we usually start with files.
| Text files in a fixed structure | Vector database (RAG) | Tool with a dashboard | |
|---|---|---|---|
| Who reads it | the agent and the person, same file | the agent, by retrieving fragments | people in the dashboard, the agent through an integration |
| How the agent knows what to read | from the map and file descriptions | from text similarity to the question | from whatever the integration exposes |
| Making a correction | edit the file, the change is visible | change the document and reprocess it | edit in the dashboard |
| When the agent gets it wrong | you can see which file it read | hard to tell which fragment drove the answer | depends on the tool |
| When it makes sense | tens or hundreds of documents someone knows | thousands of documents no one will read | when the company already works in it |
Files win in a small company for three reasons. First, they are transparent: when an agent writes something odd, you can check which file it relied on and fix that file. Second, people and agents work on the same thing, so there are never two versions of the truth. Third, there is no extra subscription and no extra place that has to be kept up to date. We save vector search for the point where there are so many documents that no person could map them. Most companies we talk to are not there yet.
What goes into the knowledge base
Everything you paste into a chat from scratch every time, and everything only one person in the company knows.
- The company: service descriptions, price list, proposal templates, how you write to clients, what the company never promises.
- Clients: a client card with the key facts, meeting outcomes, what was promised to whom and by when.
- Processes: described step by step as skills, the instructions an agent loads when it runs a given process. For example, how to prepare a brief before a client meeting or a draft proposal and follow-up.
- Rules: corrections a person made to an agent's output, written down so nobody has to make them twice.
- Decisions: what the company decided, when, who made the call and why.
- Work status: what is in progress, what is waiting on whom, what is blocked.
Companies most often skip the last two, and they save the most time. An agent that knows the decisions does not propose a solution rejected a month ago. An agent that knows the status does not start by asking where you left off.
How to structure it: state, map, detail
The most important principle: the agent reads in a fixed order. State first, then the map, and finally the detail, and only the detail the task needs. Here is how that looks in one of the projects in our own knowledge base, the one that runs our social media publishing.
State is a single file, status.md, with a table of what is true right now: what is blocked, whose court the ball is in, what was closed and when. The agent reads it at the start of any work in the project and immediately knows what not to touch and what we are waiting for.
The map is catalog.md, which lists the files in the project and what each one contains, one sentence per file. The agent does not open twenty files to find the right one. It reads the map and opens one.
Detail lives in topic files. Each decision has its own file with a header: number, date, status, who decided, followed by the decision and the reason. Each topic for publication has its own folder, and the stage it is at is a field in the file header. Nothing moves between folders when the stage changes, because several sessions work in the knowledge base at once, and moving files while someone else is editing them is a straight road to conflicts.
Four practical rules follow from this:
- One file per subject. A file called "everything about client X" eventually grows to a size nobody reads. A client card plus separate files per meeting works better.
- A description in the header. Every file opens with one sentence saying when to read it. From that sentence the agent decides whether to open the rest at all.
- State separate from knowledge. What changes daily lives in the state file. What stays true for months lives in knowledge files. That way knowledge files do not go stale with every status change.
- Dates instead of "yesterday". "Last week the client agreed to the scope" means nothing a month later. An entry with a date can always be placed in time.
Why reading order saves usage limits
Agents on Claude Team work within subscription limits. Every file an agent loads without needing it uses part of the limit and leaves less for the rest of the day. A knowledge base ordered as state, map, detail means that an agent drafting a proposal loads the state file, the map, the client card, notes from the last meeting and the price list, not the company's entire history. The same task costs less, and the result is better, because there is no noise in the context pulling the model's attention away from what matters.
The same principle works the other way too. Anything that can be checked without a model, such as whether a file has the required header fields or whether the map lists every file in the folder, is checked by a script. It is cheaper and gives the same answer every time.
People and agents on the same knowledge
A knowledge base in files is not "AI memory". It is the company's memory, which agents also use. A new team member reads the same client cards and process descriptions as the agent, so from day one they know how the company writes proposals and what it promised to whom. When someone goes on holiday, the outcomes of their meetings do not disappear into their inbox.
Our knowledge base lives in a git repository, so every change has an author and a date, and any change can be reverted. In a company that does not use git, a shared folder with version history gives the same effect. What matters is that a change to the knowledge base is visible and reversible.
How the knowledge base stays current
A knowledge base that has to be updated by hand stops matching reality within weeks. That is why in an agentic system most updates are made by agents as they work:
- after a meeting, the agent records outcomes and tasks on the client,
- after a correction by a person, the change goes into the base as a rule so the same mistake does not come back,
- after a decision, a decision file is created with a date and a reason,
- housekeeping tasks regularly check that the map matches the files and that state entries are not out of date.
That last point is not theory. In our own state file, a row about a blocker once stayed on the board for weeks after the issue had been resolved. Any agent reading it treated the blocker as current. Since then every state row carries a date and an owner, and reviewing the state is a standing task, not a matter of goodwill.
Where to start
Not by organizing all of the company's knowledge. That project never ends. Start with one process and collect only the knowledge that process needs.
- Pick a process that repeats every week, for example preparing for meetings with new clients.
- Gather what already exists: the price list, two or three good proposals, the service description, notes on a few active clients. They do not need to be tidy.
- Lay it out in files following state, map, detail, and add a sentence to each file saying when to read it.
- Describe the process as a skill: where the agent gets its data, in what order it reads the files, what the output looks like.
- Run it and correct it. Every correction that repeats becomes a rule in the base.
Once the first process works, the next ones are added on the same base and are easier, because most of the knowledge is already there. We cover the order of steps in more detail in implementing Claude in your company.
The most common mistakes
- Dumping everything in at once. A folder of five hundred documents without a map is not a knowledge base, it is an archive. The agent either reads too much or reads the wrong thing.
- No state file. Without it the agent reconstructs where you left off every time, and does it worse than a person would.
- Knowledge only for agents. When people work somewhere other than the agents, the two versions drift apart quickly.
- Corrections without a record. A fixed output with no rule in the base means the same mistake next week.
- Nobody owns the base. Agents keep it updated, but someone has to decide what is true when two files say different things.
What about company data?
The knowledge base holds information about clients, so before building it, agree on three things: what data goes in, who has access, and what processing terms apply in the Claude plan you chose. Anthropic describes the terms of each plan. This article is not legal advice: the company decides on the scope of data, and we help translate that decision into the structure of the base and its permissions.
Frequently asked questions
Does a knowledge base for AI agents need a vector database or RAG?
Not at the start. In a small or mid-sized company, knowledge usually fits into tens or hundreds of files, and an agent finds them well using the map and file descriptions. Vector search makes sense when there are so many documents that nobody could map them.
Can I keep the knowledge base in Google Drive, Notion or SharePoint?
You can keep source documents there. An agent, however, needs knowledge in a form it can read quickly and in a fixed order, so we build the agents' base in text files and extract from the source documents what the process needs.
How long does it take to build a knowledge base?
It depends on how much of the knowledge already exists outside people's heads. We build the base for the first process as part of the rollout, and each later process adds its own files.
Who maintains the knowledge base after the rollout?
Agents make most of the updates as they work, and housekeeping tasks keep it from going stale. On the company side you need someone who decides what is true and develops the system. You can also hand that part to us.
How much does it cost to roll out a knowledge base and agents?
Rolling out an agentic system, including the knowledge base for the first process, starts at PLN 9,000 net, depending on scope. On the company side there is a Claude Team subscription for each person working in the system. We break down the cost components in how much an AI agent rollout costs.
Summary
A company knowledge base for AI agents does not have to be a new system. Plain text files are enough, ordered as state, map, detail, with one subject per file, a description in the header and dates instead of "yesterday". People and agents read them, agents write their results back, and corrections turn into rules. Start with the knowledge one process needs and grow the base with each process you add.
Want to see what knowledge your company already has and which process to start with? Book a meeting at a time that suits you. It takes about an hour and ends with choosing the first process. Prefer to write first? hello@200iqlabs.io.