Agents Inherit Whatever They Are Given
A dashboard shows a number and waits for a human to interpret it. An agent interprets the number itself, says what it means, and may act on it. Whatever is wrong underneath now travels further and faster.
The guidebook described how an LLM operating on a semantically disintegrated estate will pick one of seven revenue definitions and present it with full confidence — and how engineering errors that have run long enough to look intentional get learned as valid patterns. We called this error laundering. Agents raise the stakes in three ways. They chain steps, so an early mistake propagates through every later one. They synthesize across sources, so a figure from one system and a rule from another are combined without either owner knowing. And they act: they draft credit memos, recommend reserves, prepare batch dispositions.
Three things that look like knowledge
When enterprises connect agents to "their knowledge", they usually connect three things. None of them is knowledge in the sense an agent needs.
| What agents are given | What it actually is | What it lacks | What happens |
|---|---|---|---|
| Data | Records of what happened, in ERP, CRM, LIMS and the lakehouse | Meaning, ownership of meaning, the rules and intent behind the numbers | The agent returns numbers without knowing which definition they follow |
| Information | Documents, wikis, contracts, SOPs, email | Type, structure, versions, owners, a signal of whether it is current | The agent retrieves plausible passages, some of them superseded |
| Parametric memory | Whatever the model absorbed in training | Any connection to this organization, its policies or this year's rules | The agent answers fluently about things it was never told |
Six failure modes
Agents built on those three sources fail in predictable ways. The first three were described in Documents Are Not Knowledge; the guidebook described the next two; the last becomes visible as agents move into production.
| Failure mode | What happens | What prevents it |
|---|---|---|
| Hallucination under retrieval pressure | The agent can't find a precise answer, so it generates a plausible one; in a workflow the error propagates | Typed knowledge objects with field-level answers; fail visibly when knowledge is missing |
| Persona blindness | Knowledge that is correct in general is wrong for this role, market or jurisdiction | Scope on every knowledge object; persona-aware resolution |
| Evidence collapse | The agent cannot say where an answer came from, so no one can verify or audit it | Provenance, versions and a context manifest on every answer |
| Error laundering | Inherited workarounds and defects are learned as valid business logic | Owned, validated rules; conflicts between intended and implemented behavior made visible |
| Definition roulette | One of several valid definitions is chosen silently ("net price", "released", "revenue") | Meaning resolution that disambiguates instead of guessing |
| Parametric bypass | The model answers from training — sometimes correctly — and the governed knowledge layer is never consulted | A model boundary: enterprise claims must be grounded in governed knowledge or be removed |
The last failure mode deserves emphasis because it is invisible. A model that "knows" the statutory Medicaid rebate rate will state it correctly today. When the rule changes, it will state the old one with the same confidence — and nobody will know the answer never came from a governed source. Correctness is not the test. Provenance is.
Why better retrieval will not fix it
The common response is engineering: better chunking, better embeddings, bigger context windows, re-ranking. These help retrieval. They do not tell the agent whether a retrieved passage is a binding policy or someone's opinion, whether a number is an estimate or a fact, whether a rule is still in force, or who would stand behind any of it. Those are properties of knowledge, not of retrieval — and they have to be created, owned and maintained before an agent ever asks a question.
The quality of an agent's answers is bounded by the quality of what it knows. What it knows is bounded by whether the organization has turned data and information into governed knowledge — and labeled that knowledge with how far it can be trusted.
What Makes Knowledge Knowledge
Information becomes knowledge only when it is shaped to a purpose, owned by someone with authority, and labeled with how far it can be trusted.
Five defining properties
We use a strict definition. A piece of enterprise knowledge, in the form agents need, has five properties:
| Property | Meaning | Why agents need it |
|---|---|---|
| Typed | It belongs to a declared type with a known structure — a metric definition, a control, a contract term, a model, a heuristic | So the agent knows what fields to expect and how to use them |
| Owned | A named person holds authority over it, not just responsibility for maintaining it | So someone can change it, correct it, and stand behind it |
| Governed | Changes follow rules proportional to its risk, from steward review to validated change control | So trust is earned, not assumed |
| Versioned | Every change creates a new version with rationale; past versions remain answerable | So "what did we believe then?" has an answer |
| Lifecycled | It moves through states — proposed, approved, active, under review, deprecated, retired | So the agent uses only what is current and authoritative |
Four further attributes make those properties operational: provenance (what it rests on), scope (where and for whom it applies), relations (what it depends on and conflicts with) and quality (how complete, accurate and well-evidenced it is). Together they form the envelope every knowledge object carries (Chapter 9).
The boundary between data and knowledge
An architecture for knowledge must say what it does not hold. Without a boundary, a knowledge layer either becomes a second data warehouse or loses touch with the records insights depend on. Our rule is simple: transactional and master data stay in their systems of record. Knowledge objects define, govern, predict, advise on or explain that data, and reference it — they never copy it.
| Item | Data or knowledge | Why |
|---|---|---|
| A sales order, a batch record, a journal entry | Data | A record of an event |
| A customer golden record in MDM | Data (master) | A reconciled entity record |
| The pricing procedure configured in SAP | Knowledge — deterministic | Defines how a price is computed |
| MDM survivorship and match rules | Knowledge — deterministic | Decide which source wins: a business decision |
| The definition of net sales under ASC 606 | Knowledge — definitional | Defines meaning |
| The credit policy; a contract price | Knowledge — normative | States what should happen |
| A late-payment model | Knowledge — probabilistic | A governed predictor |
| That model's score for one customer today | Data (derived) | An output of knowledge, not knowledge itself |
| A collector's rule of thumb | Knowledge — heuristic | Codified expert judgment |
| An LLM's explanation of a payment dispute | Knowledge — generated | An unverified hypothesis |
Decision-first
The guidebook's central design principle was that intelligence should flow to decisions rather than decision-makers navigating to data. For the knowledge layer this becomes a hard rule: every knowledge object must be traceable to at least one decision it informs. A knowledge object that informs no decision is a candidate for retirement. The rule keeps the layer small and precise, gives governance a reason to exist, and prevents the most common failure of knowledge programs — cataloging everything and serving nothing.
Which decision does it serve? If none, don't load it. Who has authority over it? If no one, it isn't ready. How should an agent treat it? If you can't say, it isn't classified yet.
