Ontology-Driven Agent Control: From External Fences to Internal Semantic Skeletons

In 2024-2025, Agents became the primary form of enterprise AI deployment, capable of autonomous planning, tool use, and multi-step execution. However, in real business scenarios they frequently misuse terminology, deviate in reasoning, and produce results misaligned with enterprise rules — confidently doing the wrong thing at critical nodes. The root cause is not model weakness but the lack of a "structure that knows the rules": Agents know how to work but not the industry boundaries or enterprise decision rules.

This gap drove the 2026 Q1 emergence of "Harness Engineering" — building complete constraint, feedback, and control systems so Agents act autonomously yet stay within business boundaries. The industry converged on three technical pillars: architecture constraints to limit behavioral boundaries, context engineering to manage information input, and feedback loops to verify output quality. Yet most implementations remain at the engineering patchwork level: writing prompts, listing rules, building workflows, adding permission controls. These work in simple scenarios but fail in complex business because constraints are "externally added", semantics are "implicit", and compliance relies on the model's unreliable understanding of rules.

The article advocates a different path: using Ontology to provide the semantic infrastructure for Harness systems, making constraints derive from business structure itself rather than engineering configuration. Ontology explicitly models business semantics, giving the three pillars a unified structured foundation.

Redefining the Problem: "Safe and Controllable" Is a Multi-Dimensional Engineering Proposition

Before detailing the solution, the article maps six independent yet interrelated dimensions of safe controllable execution:

Permission & Isolation: Who can do what? Can data cross boundaries? (RBAC/ABAC, API gateways, data sandboxes)

Behavioral Constraints: Where are the Agent's reasoning and invocation boundaries? (Prompt constraints, tool whitelists, ontology modeling)

Audit & Traceability: What was done? Can the decision process be reconstructed? (Operation logs, decision chain tracing, explainability frameworks)

Exception Handling: How to degrade and roll back on errors? (Circuit breakers, human review nodes, idempotent design)

Result Verification: Does output comply with business rules? (Rule engines, formal verification, ontology constraint validation)

Compliance Alignment: Does it meet industry regulatory requirements? (Compliance knowledge bases, approval flow integration, auditable reports)

The ontology-driven approach primarily addresses Behavioral Constraints and Result Verification, with substantive contributions to Audit & Traceability. It serves as the semantic infrastructure layer within a complete safety system, not a replacement for other engineering measures.

Architecture Constraints: From "External Fences" to "Internal Skeletons"

Engineering constraints face three structural difficulties in complex business: rule count grows with complexity, inflating maintenance costs; rules expressed in natural language suffer from model interpretation uncertainty and bypass risk; semantic relationships between rules and business objects are implicit, preventing cross-scenario reuse.

Ontology differs by not trying to "block" the Agent but defining its behavioral space from the start. Constraints become internal skeletons built into business structure, not external fences. Business rules are no longer natural language in prompts but explicitly modeled as queryable, verifiable structures. Tools are managed uniformly at the ontology layer — what the Agent can use, how to trigger, and execution flows are all dictated by structure, not model discretion.

Constraint enforcement occurs after Agent output but before operation execution: the system retrieves the Agent's execution intent and compares it against the ontology; violations are rejected deterministically based on traceable nodes and relationship paths, without relying on model understanding.

Context Engineering: From "Supplementing Memory" to "Restructuring How Memory Works"

Agents frequently "lose memory" in long tasks — repeatedly asking for basic information or losing context at critical nodes — because information is stacked as linear text without structure. External memory, context compression, and window expansion only alleviate, not solve, this.

Ontology takes a different entry point: enterprise data, processes, and relationships are inherently a complex association network, not linear. Ontology makes these relationships explicit, building a queryable, evolvable business semantic network that delivers three concrete improvements:

Precise Retrieval Replaces Full Injection: Before Agent startup, the cognitive engine extracts a task-relevant semantic subgraph from the ontology, dynamically injecting only the most relevant context into the reasoning context, eliminating overflow and noise at the source.

Consistency Assurance: Business knowledge is managed by a unified semantic network; expired, conflicting, or redundant records are systematically handled, so the Agent always reasons on the latest consistent information rather than potentially stale prompt fragments.

Cross-Task Reuse: The same semantic structure serves different task Agents without per-scenario context reorganization; the ontology is a continuously maintained "business map" on which Agents act, rather than starting from zero each task.

Additionally, ontology-driven context engineering resolves the long-standing split between symbolic reasoning (explainable but limited coverage) and LLM reasoning (flexible but uncontrollable). Ontology provides a collaboration framework: where structure covers, it gives deterministic constraints; where structure doesn't cover, LLM can fill in but conclusions are explicitly tagged with confidence status. Each plays its role, preserving both accuracy and flexibility.

Feedback Loops: From "Subjective Evaluation" to "Traceable Verification"

Mainstream feedback uses an "evaluator" model to judge another model's output. This has effect but clear limits: models are easily persuaded by superficially reasonable results and lack business-level correctness judgment.

Ontology offers a more direct path: objective verification based on structure, not subjective evaluation. Many enterprise judgments are essentially rule-based — whether exceeding quotas, satisfying preconditions, or complying with process logic. These don't require "understanding"; they can be directly verified. Once encoded in ontology, every Agent output can be automatically compared against business constraints, yielding a binary pass/fail.

Not all judgments can be formalized. "Hard constraints" suit ontology verification; "soft constraints" (business conventions, abnormal motives, definition of "major changes") do not. For soft constraints, ontology combines with LLM evaluation or human review nodes — complementary, not mutually exclusive.

Another feedback value is continuous ontology evolution. The ontology-Agent relationship isn't one-way constraint: ontology defines Agent capability boundaries; Agent execution touches massive business data, which feeds back to ontology — identifying uncovered concepts and relationships, flagging frequent error locations in reasoning paths, guiding ontology correction and iteration. This continuous evolution loop distinguishes it from traditional "build and forget" knowledge graphs.

Explainability is another critical value. Every verification conclusion has explicit structural basis; every judgment traces to specific rule nodes. Regulatory audit needs "system can prove compliance", not "model thinks it's compliant" — a decisive gap in finance, industrial, railway, and other strong-compliance sectors.

From Technical Control to Business Control: Knora's Implementation Path

1. Constraints Come from Business Itself, Not Engineering Assembly

Traditional Harness solutions make Agents "more stable" but within engineering boundaries — rules written by humans, constraints configured, compliance maintained via prompts. The ceiling is clear: once business complexity exceeds engineering maintenance capacity, constraints fail.

Ontology-driven approach achieves something else: constraints derive directly from business structure. Enterprise objects, relationships, rules are uniformly modeled as ontology; Agents executing tasks don't just receive context and generate — they must first enter this semantic layer, reasoning and deciding within predefined business relationships. They don't freestyle; they act within a defined "business map".

This shift brings three substantive transformations: Agents become business-semantic participants, not just execution tools; systems reuse constraints on a unified semantic foundation instead of rebuilding per scenario; business rule layer stays stable during model iteration, avoiding drift with model versions. This is the leap from "technical control" to "business control".

2. Knora's System Architecture

Yuedian Technology's Knora platform implements the methodology as a layered collaborative architecture.

Ontology Layer (Knowledge Foundation) : Stores ontology models in Labeled Property Graph (LPG). At the meta-schema level defines five core concepts: Entity (business objects like work orders, equipment, personnel), Relation (semantic connections between entities), Event (meaningful state changes in business), Action (system-executable operations with trigger conditions and parameter constraints), Logic (execution flows orchestrated by DAG engine). The key innovation: traditional ontology addresses "what is" classification; Action and Logic turn ontology from static knowledge description into executable business specifications that directly drive Agent tool calls and process orchestration. Tools are defined at ontology layer, not Agent layer — what tools, how to trigger, execution flows all decided by ontology. This layer is the system's knowledge foundation, continuously evolvable.

Cognitive Engine Layer (Translation & Arbitration) : Bridges ontology and Agent. Two core roles: (1) Before Agent startup, reads domain knowledge relevant to current scenario from ontology — entity relationships, business rules, available tools — injecting into Agent's reasoning context so Agent knows both "how this domain operates" and "which tools I can use and how". (2) After Agent generates results, retrieves conclusions and verifies against ontology constraints; violations trigger re-reasoning.

Agent Execution Layer (Task Executor) : Autonomous intelligent agent product layer. Receives user tasks, calls tools, generates results, completes execution. Pure executor — tool sourcing, usage, boundaries not self-decided but defined by ontology layer and passed via cognitive engine.

Data flow: User task → Cognitive engine extracts relevant knowledge from ontology and injects into context → Agent reasons and executes in this context → Results return to cognitive engine for ontology verification → Only after passing is final output produced. Ontology doesn't directly interact with Agent; it acts through the cognitive engine intermediary.

Concrete manufacturing example: "Work order quantity change requires approval". Full execution chain:

User intent: "Change work order WO-2026-0312 planned quantity from 500 to 800".

Cognitive engine queries ontology (LPG graph traversal): Node WO-2026-0312, type WorkOrder, state "Issued/Not Started"; attribute change magnitude 60%, exceeding ontology-defined 20% approval threshold; Action rule: over-threshold change triggers requiresApproval=true; Relation chain: WorkOrderChange → approvedBy → [BOMEngineer, ProductionManager].

Constraint verification: Current operation lacks approvedBy relation, verification fails.

System response: Blocks direct write; generates structured error report with violated rule nodes and relation paths; auto-creates approval task routed to appropriate approvers; writes operation intent to audit log with status "Pending Approval".

After approval: Adds approvedBy relation, re-verifies, passes, executes write.

3. Automated Modeling: Layered Processing with Human-Machine Collaboration

Enterprise ontology cold-start cost is unavoidable. Manual construction of sufficiently covering ontology traditionally takes weeks or months with professional knowledge engineers. Knora's strategy isn't "fully automatic in one step" but layered processing, confidence-driven, human-machine collaboration fallback. Structured, regular tasks (field-to-ontology-attribute semantic mapping, auto-generating data governance DAG flows from ontology metadata) go to automation; tasks involving business semantic judgment and concept boundary delineation aren't forced automatic. System scores confidence for each auto-generated result: high confidence executes directly, medium confidence recommends human confirmation, low confidence enters review queue — human intervention precisely targets only truly ambiguous parts. Each human confirmation or correction feeds back to system, continuously improving subsequent auto-modeling capability; as industry templates accumulate and domain samples adapt, human intervention ratio gradually decreases.

4. Real-World Deployment Status

Knora has production deployments in energy transport, electronics manufacturing, finance, and security.

Energy transport: Railway comprehensive inspection report generation Agent automatically constructs indicator systems and generates reports, transforming work that originally required 30 people / 7 days to organize data and write reports into 3 people spending one day verifying data + Agent completing in 30 minutes — over 70x efficiency gain. Across dozens of scenarios including safety hazard identification, maintenance plan generation, emergency plan generation, emergency resource scheduling, it serves as "digital employees" undertaking actual business responsibilities.

Electronics manufacturing: Around core scenarios like quality traceability and defect analysis, converts experience-dependent manual processes into precise knowledge-driven automated digital business flows.

Conclusion

AI's entry into enterprise is undergoing a fundamental fork. One path keeps stacking tools, accumulating prompts, doing integration — Agents run but no one truly knows where they'll go or what results they'll produce. The other path first builds business structure, letting Agents act on a clearly defined semantic map — they know where boundaries are, what rules are, and the basis for every decision step.

Short-term cost difference between the two paths is small, but the gap after one year, three years will show in every moment needing to explain decisions to regulators, every multi-system collaboration with semantic chaos, every critical node where an Agent "confidently does the wrong thing".

Enterprise AI competition ultimately isn't between models, but who first structures their own business knowledge . Enterprises that close this loop first accumulate not just a system, but a continuously self-evolving business intelligence foundation — becoming more accurate with every Agent execution, more complete with every business iteration.

The real moat is never bought tools, but precipitated cognition. Agents will be replaced, models will be iterated, but business cognition沉淀 in ontology won't — that's the reason to start now.