There is a pattern I now see often enough to predict.
A company builds an assistant, connects it to the document store, and demonstrates it answering a question well. Everyone is encouraged. It goes to a pilot group, who use it for two weeks and then stop, because it confidently produced an answer from a policy that was superseded eighteen months ago.
The model was not the problem. The knowledge environment was, and nobody had designed one.
Why the document store fails
Enterprise documents are written for people who already know things. That is not a flaw in the documents. It is what makes them efficient for their actual readers, and it is exactly what makes them poor raw material for a system that knows nothing.
Four specific failures show up every time.
Documents contradict each other and nothing says which wins. Three versions of the expense policy exist. A person knows to check the intranet rather than the shared drive. Retrieval has no such instinct and will happily cite the wrong one.
Nothing carries its own expiry. A document does not say that it stopped being true when the product was renamed. Freshness lives in the heads of the people who were there.
The context is missing. Any document assumes the reader knows the business, the vocabulary, and the twenty exceptions that everyone internalises in their first year. None of that is written down anywhere, because writing it down was never necessary.
Permissions get flattened. This is the dangerous one. A retrieval layer with broad access to everything becomes a route around the access model the company spent years building. The agent becomes the most over-permissioned employee in the organisation, and it never gets tired of answering questions.
What a corpus actually is
A corpus is the deliberately designed knowledge environment an agent works from. It is not a copy of the document store, and it is usually much smaller.
It has scope, because it exists to support particular work rather than all work. It has canonical sources, so that for any question it can answer there is one right place. It carries permissions, so that what the agent can see depends on who is asking. It knows what is current. And it contains the context that documents assume, made explicit.
Building one is less about retrieval technology than most teams expect, and much more about decisions the business has avoided making.
Designing one
Start from the work, not from the content. List the questions the agent must answer and the tasks it must complete. Everything else follows. A corpus scoped to a customer support workflow is a different object from one scoped to procurement, and trying to build the union of both produces something that serves neither.
Establish canonical sources and say so. For each area of knowledge, one place is authoritative. This is frequently the moment a programme stalls, because agreeing that the finance team's version wins over the operations team's copy is a political act rather than a technical one. It still has to happen. An agent cannot arbitrate between sources that the organisation itself has never reconciled.
Carry permissions through, do not flatten them. Retrieval should run as the person asking, not as a service account with access to everything. This is more work and it is not optional. The alternative is a system that will eventually surface a salary review to the wrong person, and that is the kind of incident that ends programmes.
Write down what the documents assume. The tacit layer: what the terms mean here, which exceptions apply, how the process actually runs as opposed to how it is documented. This material usually does not exist in any file and has to be captured from people. It is the least glamorous work in the whole exercise and it produces the largest improvement in answer quality.
Give everything an owner and a review date. Content without an owner rots silently. The corpus needs the same governance any other production dependency gets, which means someone whose job includes it rather than someone who volunteered.
Measure retrieval against the questions you scoped. Not against a generic benchmark. Take the real questions, check whether the right material is being found, and grow the test set every time it is not. Retrieval failures and reasoning failures look identical from the outside and need completely different fixes, so it is worth being able to tell them apart.
The part nobody wants to own
The technical work here is tractable. The organisational work is what determines whether it lasts.
A corpus needs a custodian. Someone accountable for what is in it, what has been retired, who can see what, and whether it still answers the questions it was built for. In most companies this role does not exist, and the corpus is maintained by whichever engineer built it until they move to another project.
That is why corpora decay. Not because the technology degrades, but because the business keeps changing and nothing in the system notices.
If you are building agents and cannot name the person who owns the knowledge they depend on, you have found your next hire before your next model decision.
What this buys you
A well-designed corpus is one of the few genuinely durable assets in enterprise AI.
Models will keep improving and will keep becoming cheaper, and whichever one you chose this year is unlikely to be the one you use in three. What does not commoditise is a trusted, current, permission-aware account of how your organisation actually works. That is specific to you, expensive for anyone else to reproduce, and it makes every subsequent agent cheaper to build.
Companies that treat the corpus as the foundation end up with compounding capability. Companies that treat it as a data-loading step keep rebuilding the same disappointing assistant with a better model underneath.
Knowledge is one of the six things every enterprise agent needs, and it is the one most often assumed rather than designed.