Open the designed HTML edition — the full 18-chapter point of view, with every figure, table and appendix.
Executive Summary
Every enterprise now has access to capable models. What separates them is what their agents know — and whether anyone can tell how far to trust it.
Most enterprises give their agents three things that look like knowledge and are not. Data in systems and lakes records what happened, but not what it means. Information in documents and wikis holds meaning, but it's untyped, unowned and unversioned. And parametric memory — whatever the model absorbed in training — answers fluently on behalf of an organization it has never met. Agents built on these three things produce confident answers in which a fact, an estimate, a policy and a guess all sound exactly the same.
This isn't a hypothetical. Commercial and finance teams in regulated industries are already building agents — content generation, CRM next-best-action, Talk-2-Data analytics, invoice automation, variance commentary. Each is a sensible investment. But most are Siloed Agents: purpose-built, with their own definitions, rules and memory locked inside their own harness. Each knows its stage. None knows the process. Played forward, a siloed estate plateaus on accuracy, relevance and efficiency — and every new agent costs more to build than the last.
The answer isn't fewer agents. It's end-to-end, enterprise-grade knowledge that every agent shares.
Contents
Key takeaways
(1) Data, documents and model memory all look like knowledge to an agent, and none of them are. (2) A Siloed Agent estate automates fragmentation, it doesn't fix it. (3) Knowledge needs six epistemic classes and a profile — class, origin, assurance — that an agent must obey. (4) The architecture is a capability stack, not a bigger data lake. (5) Start from three decisions, not a platform.
Section 01 · The Knowledge Problem
The Knowledge Problem
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.
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 get combined without either owner knowing. And they act — drafting credit memos, recommending reserves, preparing batch dispositions.
Data
Records what happened — in ERP, CRM, LIMS, the lakehouse. It lacks meaning, ownership of meaning, and the rules behind the numbers. The agent returns a figure without knowing which definition it follows.
Information
Documents, wikis, contracts, SOPs. It lacks type, structure, versions, owners, and any signal of whether it's current. The agent retrieves plausible passages — some of them superseded.
Parametric memory
Whatever the model absorbed in training. It lacks 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 follow from this: hallucination under retrieval pressure, persona blindness, evidence collapse, error laundering, definition roulette, and — the one that's easiest to miss — parametric bypass, where the model answers correctly from training today and will state the same stale answer with the same confidence after the rule changes, because the governed knowledge layer was never consulted. Correctness isn't the test. Provenance is.
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.
Section 02 · The Siloed Agent
The Siloed Agent
A Siloed Agent is a purpose-built agent whose knowledge — its definitions, rules, context and memory — is assembled inside its own harness for its own use case, rather than drawn from a shared, governed layer that follows the end-to-end process.
Nobody builds these on purpose. Each use case has a sponsor, a budget, a deadline. Vendors ship agent features inside the systems people already use. Keeping scope narrow makes compliance review tractable. All of that is sensible — the cost only shows up in aggregate, as six symptoms: contradiction between agents, re-implementation of the same rule in ten harnesses, people becoming the glue between agents, untraceability, brittleness, and amnesia.
Played forward across a year or two, the pattern looks familiar: pilots and wins, then scale and contradiction, then an estate of individually useful agents that reproduce the fragmentation they were meant to overcome — a shadow context layer as hard to unwind as the shadow semantic layer that self-service BI left behind. Better models don't fix this. A stronger model reasoning over a private, partial context just produces a more convincing partial answer.
The fix isn't fewer agents. It's moving their knowledge into a layer every agent shares — harvesting what's already sitting in prompts, retrieval indexes and guardrails, and re-pointing agents at it.
Section 03 · Six Kinds of Knowledge
Six Kinds of Knowledge
A definition, a rule, a policy, an estimate, a rule of thumb and a hypothesis are different kinds of statement. An agent that treats them alike will eventually present a guess as a fact.
| Class | What it is | Agent verb | How it may be used |
|---|---|---|---|
| Definitional | What a concept means | RESOLVE | Never paraphrase — resolve the canonical meaning |
| Deterministic | A rule or calculation: same input, same output | EXECUTE | Execute it, pinned to a version |
| Normative | What should happen — policy, plan, contract term | COMPARE | Compare actuals against it, as a commitment |
| Probabilistic | A quantified estimate from a model | ESTIMATE | Invoke the model, report an interval |
| Heuristic | Codified expert judgment | ADVISE | Advise, with scope and hit rate shown |
| Generated | Model-produced synthesis or hypothesis | HYPOTHESIZE | Present as unverified, never as fact |
A seventh category — fact references — points into systems of record rather than copying them, so an agent can cite a live fact without restating it from memory.
The separation matters in practice. A definition says what net revenue means; a deterministic rule says how a system actually computes it — and the two can disagree, which is exactly the gap between what was intended and what got implemented. A probabilistic estimate's uncertainty is calibrated and backtestable; a generated explanation's uncertainty is not — the same prompt can answer differently tomorrow, and nothing measures how often it's right.
Section 04 · The Epistemic Profile
The Epistemic Profile
Before an agent uses any piece of knowledge, it needs to know four things: what kind of knowledge it is, who or what wrote it, who has vouched for it, and therefore how it may be used.
Every knowledge object carries this profile. Class is one of the six above. Origin — human-authored, system-extracted, machine-derived, AI-generated, or AI-drafted-and-human-edited — is fixed for each version and never upgraded; an AI-authored rule stays AI-authored even after a human approves it, because the approval is recorded as assurance, not as a change of origin. Assurance runs from A0 (unverified) to A4 (formally validated), and it expires — knowledge validated long ago reverts to unverified until someone checks it again. Treatment is derived from the other three, never typed in directly by hand, and an owner may tighten it but never loosen it.
That last rule is deliberate. It's the one place the model removes human discretion, because the failure mode it exists to prevent — a confident agent built on loosely labeled knowledge — is the whole point of the architecture.
In practice this looks like: "Accrual for claims not yet received: $62.0M (±$6M). [probabilistic · machine-derived · formally validated (A4) · model calibrated Sep 2026]" — a number, and what kind of number it is.
Section 05 · The Architecture
The Architecture
The capability stack runs from humans acting — whose actions get codified in systems — through the data platform and the knowledge layer to the agent runtime, to humans deciding, and loops back. Six components give it one vocabulary:
KDEFINE · KLOAD
KDEFINE declares what counts as valid knowledge and how agents must treat each kind — the architecture's constitution. KLOAD extracts, contextualizes and loads sources into proposed knowledge objects; everything lands as Proposed unless policy allows automatic validation.
KSTORE · KQUERY
KSTORE holds knowledge objects, versions, states and relations across several engines — references data, never copies it. KQUERY is the only way agents reach knowledge: it asks which decision this is for before what data is needed, and returns every claim labeled.
KFLOW · KMONITOR
KFLOW promotes, propagates and retires knowledge as it changes — no change is silent. KMONITOR tests whether knowledge is current, whether agents use it faithfully, whether governance is real, and whether decisions actually improved.
Four rules hold the stack together. Context is assembled at runtime for each request and never stored as a layer — only a context manifest persists, so any answer can be reproduced and audited. Models supply language and reasoning, never enterprise facts. Agents act through systems, never around them, so existing authorizations and audit trails still apply. And vendor-embedded agents — the ones already living inside your CRM and ERP — consume the same enterprise knowledge, or declare the limits of what they can answer.
Section 06 · Life Sciences: A Stress Test
Life Sciences: A Stress Test
Pharma is the hardest test we know for a knowledge architecture: definitions carry legal weight, estimates flow into reported revenue, and release decisions belong by law to named people. The model holds up across three value chains.
In order-to-cash, most of the hard knowledge sits in gross-to-net — rebates, chargebacks and government pricing — where reported net revenue is itself partly an estimate. A single quarterly net-sales figure can be a third fact reference, a third probabilistic model output, and a sliver of human judgment, each labeled separately rather than blended into one falsely precise number.
In plan-to-produce, "released" turns out to have at least four meanings across QC, QA, a Qualified Person's certification and the ERP status field — and release is a human-only decision by law. The architecture's answer: a validated, deterministic rules engine decides readiness; generative AI is assistance only, labeled and verified, and never authors a GxP record.
In record-to-report, one reported figure combines facts, rules, estimates and judgment under accounting policy, and true-ups are where the estimates get graded against reality.
Each chain gets a first wedge — chargeback validation, batch record review by exception, gross-to-net reserve review — defined by one decision, not a capability, and sequenced by regulatory burden rather than by what's easiest to build first.
Section 07 · What Is Genuinely Different
What Is Genuinely Different
The knowledge layer is not a better data lake, a richer catalog, or a larger vector store. A warehouse returns 226.0. The knowledge layer returns 226.0 and what kind of number it is — its class, its origin, who vouched for it, and when it expires.
Vendors are converging on real infrastructure for this — SAP pairs Business Data Cloud with a knowledge graph for its Joule agents; the Open Semantic Interchange initiative, now Apache Ossie, has Snowflake, Salesforce, dbt Labs and others behind a shared specification. That's welcome, and it covers one class well: definitional knowledge — metrics and dimensions. What no vendor supplies is the organization's own content, owners with actual authority, and the normative, probabilistic, heuristic and generated classes that carry the rest of what an enterprise knows. Vendors supply the container. The organization supplies — and stands behind — what goes in it.
Section 08 · Where to Start
Where to Start
Do not launch a platform. Launch three decisions, and build only what they need.
Start with one decision per value chain — chosen where failure costs money visibly, where it gives an influential skeptic real time back, or where it crosses a boundary no current system bridges. Define before you load: declare only the knowledge types those decisions actually need. Load narrowly — resist the pull to index every repository, because that produces a knowledge swamp with better branding. Gate every go-live on golden questions passing and every object having an owner. And measure decisions, not usage: dispute rates, cycle time, close days, true-up variance — not active users.
The first loads will surface conflicts and gaps nobody had named out loud — a policy that disagrees with system configuration, a rule with no owner, an overlay with no recorded rationale. That's not the architecture failing. It's the first time the organization has seen its own knowledge clearly, and it's the most persuasive evidence a sponsor will see that the work is worth doing.
The question is not whether an organization's agents can answer. It is whether the organization could stand behind the answer — and show how it knows.
Read the Full Point of View
This is a condensed summary. The full point of view — all 18 chapters, every figure and table, the complete life sciences deep-dive across three value chains, and six appendices including specifications for architects — is published as a designed reading edition.