An agent does not draw on one undifferentiated pool of knowledge. It draws on four distinct kinds, and they belong in separate homes. When you understand the difference, you can give each one the right place, and the agent stops guessing.
The four kinds
- Training knowledge, what the model knows about the world in general. It knows what an invoice is, what double-entry bookkeeping means, what currencies exist. This knowledge came from training and lives inside the model.
- The data it works on, the actual material for this job. In the monthly financial-document run, this is the batch of receipts and invoices in front of the agent right now.
- Operating knowledge, what it needs in order to work on that data: where things live, how the job is wired, what step comes after what. This is the map of your process, not the data itself.
- Your local knowledge base, your own standing facts and standards, the brief it reads each run. This is where you record that a particular supplier always bills a month in advance, that a particular category of receipt should be coded a particular way, that your organisation uses a specific chart of accounts.
Why the separation matters
The problem is not that the agent lacks knowledge. The problem is that it blends kinds when it should not. Training knowledge tells it what an invoice is. Your local knowledge base tells it how your invoices work. When those two stay in separate homes, the agent can reach for the right one. When they are mixed, it interpolates, and that is where the errors come from.
Here is the case study point exactly. Your supplier always bills in advance: the invoice arrives this month, the service is delivered next. That fact is not in the model’s training. It is yours, and it belongs in your local knowledge base. An agent running without it will record the entry against the wrong period, because it is drawing on general accounting knowledge rather than your standing facts. The entry looks plausible. It is wrong.
What happens when the kinds are confused
While building this course, an agent confused the data it was working on with its operating knowledge, treating a flat file as if it were the source of truth about where things lived. It placed a value in the wrong location, the correct value drifted, and hours of reconstruction followed. The kinds were not wrong individually. They were in the wrong places, and the agent could not tell them apart.
That is the failure mode. It is not dramatic. It looks like a confident, plausible answer, grounded in the wrong kind of knowledge for the task.
One kind, one place
Before you build your local knowledge base, you need to know which of the four kinds of knowledge belongs there. Training knowledge stays in the model: you do not need to copy the definition of an invoice into your brief. The data the agent works on sits in the job itself, not in the brief. Operating knowledge belongs somewhere the agent can consult about how your process is wired. Your standing facts and standards, the things the model cannot know because they are specific to you, belong in the local knowledge base the agent reads each run.
One kind, one place. That decision, made clearly before you write a single line of your knowledge base, is what separates an agent that answers correctly from one that answers confidently.