Knowledge Compilation: The Semantic Layer Enterprise Agents Need

Why Enterprise Agents Fail Without Knowledge Compilation

Current large language models and agents handle single-user tasks (coding, data analysis, report generation) adequately. However, when deployed across business lines or entire enterprises, they produce plausible but incorrect answers because input knowledge has not been "understood." Three concrete failures illustrate the gap:

Retail customer service: An agent cites a return policy but misses the sales channel, product category, campaign batch, and rule effective date, applying an irrelevant rule to the current order.

Financial compliance: An agent conflates contract counterparty, payer, and beneficial owner into a single "customer," yielding a wrong risk judgment.

Aviation maintenance: An agent mixes repair experience from engine model B into the answer for model A; the two models differ by one letter but have completely different fault causes and procedures.

Frontline staff dare not adopt these answers. The problem is not generation quality but that raw knowledge was never compiled into a form agents can truly consume.

What Knowledge Actually Is

Knowledge is not documents or data tables—those are merely recording forms. Knowledge consists of concepts, entities, facts, relationships, and rules that are jointly explained, constrained, and verified by scattered artifacts. Three properties define it:

Composed of concepts, views, entities, and their organizing relationships. A vehicle spec records the battery type; a parts list records the supplier; a quality bulletin flags a batch risk. Only linking "vehicle → model → battery → batch → bulletin" lets an agent judge whether a specific car is affected.

Requires clear semantics, applicability boundaries, and factual evidence. Answering "how many paternity leave days?" demands combining region, employment relationship, request time, and the currently effective policy version. Correct facts with wrong boundaries still produce wrong answers.

Scale is measured by responsible subjects, not document count. Sales, finance, and legal each have 10 documents about "customer," "order," and "completion" that mean different things. Enterprise knowledge emerges only after each department's definitions are internally consistent and cross-mapped.

The boundary of a compilable knowledge set is a business knowledge unit —a single authority responsible for the consistency of concepts, facts, and rules.

Knowledge Compilation: From Raw Materials to Agent-Consumable Forms

Retrieval (finding relevant document chunks) is not understanding (resolving what objects are involved, how they relate, under what conditions rules hold, and whether evidence shares a business context). Just as source code must be compiled before a CPU can execute it, raw enterprise artifacts must be compiled into target shapes agents can directly consume.

There is no single target shape; the output depends on (1) the complexity of the knowledge structure in the source materials and (2) how downstream tasks will consume the knowledge. The article maps industry archetypes to compilation targets:

Manufacturing, energy (entity-relationship heavy): part queries, equipment configuration traceability, change impact analysis → ontology semantic graphs for multi-hop traversal over stable relations.

Finance, tech (knowledge-intensive): policy interpretation, product research, complex Q&A → LLM Wiki to complete context, conditions, and exceptions from scattered articles and cases.

Retail, government (process-intensive): customer service, account opening review, compliance checks → SOP with explicit conditions, steps, and deliverables.

Automotive, industrial equipment ops (fault-intensive): charging interruption, equipment alarms, quality anomalies → Fault Tree Analysis (FTA) for layered root-cause investigation from symptoms.

Internet, new retail (data-intensive): natural-language querying, table selection, data development → data semantic layer mapping stable business semantics to evolving data assets.

RAG is a runtime retrieval method that can combine with any compilation product; it is not an alternative compilation target. Enterprises need a unified compilation foundation—fact sources, evidence, versioning, and the "consume-feedback-recompile" lifecycle—not a single monolithic graph.

Agent-Native Compilation: Explore–Review–Confirm in Dialogue

Traditional knowledge engineering used manual schema design, instance annotation, and graph review—slow, expensive, and brittle to business change. The agent era offers a new path, but not "one-click auto-generation." Compilation is high-stakes: a wrong alias merge, reversed relation, or misaligned definition propagates errors to every dependent agent.

The process is an iterative explore–review–confirm loop:

Explore: Agent scans heterogeneous materials and proposes candidate schemas, instances, and relations—surfacing a model skeleton.

Review: Conflicts, alias merges, and definition divergences are made explicit for business owners to decide (e.g., "Is A320 the canonical name?" "What does 'completed' mean in after-sales vs. settlement?"). Systems cannot infer these decisions.

Confirm: Approved rules are batch-executed by the agent to generate versioned artifacts. When business changes, the cycle repeats.

This is inherently a human–AI collaborative, iterative process—neither a static one-time pipeline nor purely manual. Only a conversational agent can execute the bulk work while surfacing key decision points for human adjudication. In practice, ontology semantic graph construction for a domain shrank from weeks to hours .

Knowledge Servitization: Turning Compilation Products into Evolving Capabilities

Compilation is step one; the goal is to turn products into capability supply that amplifies agent productivity. Example: EV charging fault diagnosis.

Ontology organizes vehicle, charging session, and charger as identifiable, linkable objects.

Fault tree structures possible causes and diagnostic evidence into investigation paths.

SOP maps each cause to a remediation action.

With these, the agent verifies real-time session state step by step, locks the root cause, and outputs an executable remediation plan—not just a list of possibilities.

Three delivery modes serve different consumers and integration styles:

API/MCP — standard interfaces for traditional programmatic integration (business systems, backend services).

Skill — agent-oriented capability orchestration; can wrap a single knowledge asset or an entire knowledge space, combining multiple compilation products with RAG into callable skill units.

ACP (Agent Context Protocol) — standardized agent access exposing knowledge assets and knowledge closures, enabling on-demand discovery, retrieval, and consumption during reasoning.

The distinction is consumer and integration mode , not artifact size. API targets systems; Skill and ACP target agent ecosystems (Skill emphasizes encapsulation and orchestration; ACP emphasizes protocolized access). Consumption granularity is orthogonal: the same underlying assets can be exposed as a single asset or as a domain-level knowledge space/closure.

This creates a continuous loop: compile → capacitize → consume → feedback → recompile . Each feedback round triggers a new explore–review–confirm cycle, producing a new version and updating the published capability. The result is not a static knowledge asset but a domain capability that evolves with business use.

Three-Layer Architecture: Enterprise Knowledge, Personal Knowledge, Agent Applications

The root cause of agent adoption failure is not model size, prompt tricks, or RAG tuning—it is that enterprise raw materials were never seriously "understood" for agents. Knowledge compilation solves "what agents need."

But knowledge producers are individual employees. The person instructing the agent relies on context scattered in IM chats, email threads, meeting transcripts—highly personal, strongly temporal, noisy, yet essential for the agent to "truly understand this person and situation."

Therefore, enterprise knowledge management and personal knowledge management become twin tracks:

Enterprise knowledge construction layer: centralized ingestion, processing, compilation; top-down governance; strict permissions. Answers "how is this defined in the organization?"

Personal knowledge management layer: individually controlled knowledge spaces; can store private context and selectively incorporate company knowledge; builds complete personal context. Answers "what is the progress, judgment, and preference in my view?"

Agent application layer: diverse agent tools connect to personal knowledge bases for creation and output; applications decoupled from knowledge, letting the same knowledge serve multiple agents.

The endgame: today, compile enterprise knowledge solidly so agents "understand the organization"; tomorrow, hand the same lightweight capability to every individual so agents ultimately "understand the person and the situation." When both layers interoperate under one compilation paradigm, the organization gains a trustworthy, reusable, continuously growing knowledge capability layer—belonging to the organization and to each person.