What enterprise agents actually need from knowledge

The question people ask about enterprise agents and knowledge is usually the wrong one. They ask "how much knowledge does the agent need?" as if the answer were a number, or a threshold, or a knowledge base big enough to be safe. The real question is narrower and more useful: what does the agent actually need from knowledge, in what shape, and how do we know it is the right knowledge.

The answer, in the large, is that enterprise agents fail less from not knowing enough than from acting on the wrong slice of what is known. The knowledge is in the building. The problem is not ignorance. The problem is that the agent is acting on an assembly of stale, unowned, ungrounded knowledge and calling it truth.

The wrong question and the right one

The wrong question is "can the agent read our documents?" The agent can read the documents. The question is whether the agent is reading the current version, the version the company trusts, the version it is allowed to act on, and whether the company can tell what it read when the agent acts.

The right question is "what does the agent need from knowledge in order to do the thing we are asking it to do — and how do we know it has the right knowledge for that thing, in the right shape, at the right moment." This is a smaller question and a harder one, because it is about the knowledge the agent will actually touch, not the knowledge the company has.

The knowledge enterprise agents actually need

For most enterprise agents, the knowledge they actually need is not the whole company. It is the specific knowledge for the specific thing they are doing — the current procedure, the current value, the current owner, the current permission. The rest is background, and background can wait until it is needed, or it can stay out of the context entirely.

The knowledge they need has a few properties, and these are the properties that matter more than the volume:

Currentness. The agent must be able to tell what is current — not by guessing, not by assuming the latest document is the latest truth. The procedure was updated last month. The agent is following the version from two versions ago. Nobody told the agent. Nobody told the document. The knowledge is not missing; it is just not current, and the agent is acting on the old version as if it were the new one.

Ownership. The agent must be able to tell who owns the knowledge it is acting on — the person or system responsible for it being true. Without ownership, the agent is acting on an unowned assembly of half-truths, and the company has no one to ask when it goes wrong. Ownership is what makes deprecation possible, and deprecation is what makes currentness credible.

Deprecation. The knowledge that is no longer true must be retired, marked, and removed from the agent's usable picture. This is the most expensive failure mode at enterprise scale, because it is the one that looks fine until it is not — and by then the agent has been acting on it for weeks. The agent that cannot tell the retired version from the current one is the agent that acts on the retired version as if it were current.

Permission. The agent must know what it is allowed to use and what it is not allowed to use. The boundary between "can see" and "can act on" must be explicit, because the enterprise is full of knowledge that is real and not for the agent. The agent that can see the salary but cannot act on it is the agent that is useful without being a liability.

Grounding. When the agent says or does something, it must be able to show what knowledge it used — in what shape, from where, at what version, with what permission. Grounding is what makes the agent auditable, and auditability is what makes the enterprise willing to let it act.

The shape matters as much as the content

The shape of the knowledge matters as much as the content, because the shape is what the agent pays to re-derive if it is not already in the right shape. Send the agent the whole document and the agent pays to find the procedure in it. Send the agent the procedure in the shape the agent can use, and the agent pays for the procedure, not for the extraction.

This is the same discipline as the token-savings argument — send less of the right knowledge, in the right shape — and it is the same discipline as the grounding argument — make the basis retrievable, with the currentness and permission attached. The shape is the bridge between cost and trust. The wrong shape costs more and trusts less. The right shape costs less and trusts more.

What "good enough" means

Good enough does not mean the whole company. It means the knowledge the agent needs for the thing it is doing — current, owned, retired when it is no longer true, permitted, and groundable. It means the agent can show its basis when asked, and the company can tell whether that basis was the right one.

Good enough is a smaller bar than the company's knowledge. It is a higher bar than the knowledge the agent happens to be reading. The gap between the two is where most enterprise agents fail — not from not knowing enough, but from acting on the wrong slice of what is known.

The practical takeaway is not "build a knowledge base for the whole company." The practical takeaway is to find the one or two knowledge domains the agent will act on, and to put currentness, ownership, deprecation, permission, and grounding on the knowledge for those domains before the agent is asked to act on them at scale. The rest can wait. The one or two domains cannot.