Ontology-Driven Agent Control: The Semantic Backbone for Harness Engineering

From Agent Hype to "Uncontrollable" in Production

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

Harness Engineering and Its Three Pillars

By 2026 Q1, "Harness Engineering" emerged as the industry term for building complete constraint, feedback, and control systems around Agents. The industry converged on three technical pillars: architectural constraints to bound behavior, context engineering to manage information input, and feedback loops to verify output quality. However, most implementations remain at the engineering patching level — writing prompts, listing rules, building flows, configuring permissions. These work for simple scenarios but expose a deep structural flaw in complex business: constraints are "externally added", semantics are "implicit", and compliance relies on the model's unreliable understanding of rules.

Ontology as Semantic Infrastructure

The article proposes a different path: using Ontology to provide the semantic infrastructure for the Harness system, 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 "Safe and Controllable" as a Multi-Dimensional Engineering Problem

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

Permission & Isolation — Who can do what? Data cross-boundary? (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 conform to 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 contribution to Audit & Traceability . It serves as the semantic infrastructure layer within a complete safety system, not a replacement for other engineering measures.

Architectural Constraints: From "External Fences" to "Internal Skeleton"

Engineering constraints face three structural difficulties in complex business: rule count grows with complexity, maintenance costs balloon; rules expressed in natural language leave model understanding uncertain and bypassable; semantic relationships between rules and business objects are implicit and non-reusable across scenarios.

Ontology differs by not trying to "block" the Agent but defining its behavior space upfront. Constraints become an internal skeleton built into business structure, not an external fence. 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 dictated by structure, not model discretion.

Verification occurs after Agent output but before operation execution: the system retrieves the Agent's execution intent and compares it against the ontology. If predefined rules are violated, it rejects and forces re-reasoning; it never silently permits. The verification basis is traceable nodes and relationship paths in the structure; the conclusion is deterministic, not dependent on model understanding.

Context Engineering: From "Supplementing Memory" to "Reconstructing Memory"

Agents frequently "lose memory" in long tasks — repeatedly asking for basic information or losing context at critical nodes. The root cause is linear text stacking without structure. External memory, context compression, or window expansion only alleviate, not solve.

Ontology takes a different entry point: enterprise data, processes, and relationships are inherently a complex association network, not linear. Ontology makes this network explicit, building a queryable, evolvable business semantic network. This brings three substantive improvements:

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

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

Cross-Task Reuse : The same semantic structure serves different Agents across tasks, eliminating 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 and LLM reasoning. Traditional knowledge graphs are explainable but limited in coverage; pure LLM reasoning is flexible but uncontrollable. Ontology provides a collaboration framework: where structure covers, ontology 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 mechanisms introduce an "evaluator" model to judge another model's output. This has some effect but clear limits: models are easily persuaded by superficially reasonable results and lack judgment on business-level correctness.

Ontology offers a more direct path: objective verification based on structure, not subjective evaluation. Many enterprise judgments are essentially rule-based — whether exceeding quota, satisfying preconditions, conforming to 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 — pass or fail.

Not all judgments can be formalized. "Hard constraints" suit ontology verification; "soft constraints" do not — e.g., whether a decision follows business convention, whether abnormal motives exist behind an operation, or the definition of "major change" itself involves subjectivity. For soft constraints, the ontology approach combines with LLM evaluation or human review nodes, complementary not mutually exclusive.

Another value of the feedback loop is continuous ontology evolution. The relationship between ontology and Agent is not one-way constraint: ontology defines Agent capability boundaries; Agent encounters massive business data in real execution, which feeds back into ontology — identifying uncovered concepts and relationships, marking frequent error locations in reasoning paths, guiding ontology correction and iteration. This continuous evolution loop is the core difference 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 and relationship paths. Regulatory audit needs not "model thinks compliant" but "system can prove compliant". This gap is decisive in high-compliance industries like finance, industrial, and railway.

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

1. Constraints 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 come directly from business structure. Enterprise objects, relationships, rules are uniformly modeled as ontology; the Agent doesn't just receive context and generate but must first enter this semantic layer, completing reasoning and decision within predefined business relationships. It acts on a defined "business map", not free play. This brings three substantive shifts: Agent becomes a business-semantic participant, not just an execution tool; system reuses constraints on a unified semantic foundation instead of rebuilding per scenario; business rule layer stays stable during model iteration, not drifting 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)

Bottom layer stores ontology model in Labeled Property Graph (LPG). At the meta-schema level, five core concepts are defined:

Entity — business objects (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 defined by DAG orchestration engine

Key design: traditional ontology mainly solves "what is" classification; Action and Logic turn ontology from static knowledge description into executable business specification, directly driving Agent tool calls and process orchestration. Tools are defined at ontology layer, not Agent layer — what tools Agent can use, how to trigger, execution flows are 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 — injects into Agent's reasoning context, so Agent knows both "how this domain operates" and "what tools I can use and how". (2) After Agent generates results, brings conclusions back for ontology constraint verification; if ontology-defined rules violated, rejects and forces re-reasoning.

Agent Execution Layer (Task Executor)

Autonomous intelligent agent product layer. Receives user tasks, calls tools, generates results, completes execution. Pure executor — tool origin, 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 into context → Agent reasons and executes in this context → Results return to cognitive engine for ontology verification → Only after passing, final output. Ontology does not directly interact with Agent; it acts through the cognitive engine intermediary.

Concrete Example: Manufacturing Work Order Change Requiring Approval

(1) User Intent : "Change work order WO-2026-0312 planned quantity from 500 to 800"

(2) Cognitive Engine Queries Ontology (LPG Graph Traversal) :

Node: WO-2026-0312, type WorkOrder, status "Issued/Not Started"

Attribute: Change magnitude 60%, exceeding ontology-defined 20% approval threshold

Action Rule: Over-threshold change triggers condition requiresApproval = true

Relationship Chain: WorkOrderChange → approvedBy → [BOMEngineer, ProductionManager]

(3) Constraint Verification : Current operation lacks approvedBy relationship; verification fails.

(4) System Response :

Block direct write

Generate structured error report carrying specific violated rule nodes and relationship paths

Auto-create approval task, route to corresponding approvers

Write operation intent to audit log, status "Pending Approval"

(5) After Approval : Supplement approvedBy relationship, re-verify pass, execute write.

3. Auto-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 is not "fully automatic in one step" but layered processing, confidence-driven, human-in-the-loop fallback. Structured, pattern-clear tasks (e.g., field-to-ontology-attribute semantic mapping, auto-generating data governance DAG flows from ontology metadata) go to automation; tasks involving business semantic judgment, concept boundary definition are not forced automatic. System assigns confidence scores to 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, continuously improving subsequent auto-modeling capability; as industry templates accumulate and domain samples adapt, human intervention ratio gradually decreases.

4. Real-World Deployment Results

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

Energy Transport : Railway comprehensive inspection report generation Agent automatically constructs indicator systems and generates reports. Work originally requiring 30 people / 7 days to organize data and write reports becomes 3 people spending one day verifying data + Agent 30 minutes auto-completion , efficiency improvement over 70x . In safety hazard identification, maintenance plan generation, emergency plan generation, emergency resource scheduling, and dozens of other scenarios, it serves as "digital employees" undertaking actual business responsibilities.

Electronic Manufacturing : Around core scenarios like quality traceability and defect analysis, transforms experience-dependent manual processes into precision-knowledge-driven automated digital business flows.

Conclusion: The Fork in Enterprise AI Adoption

AI's entry into enterprise is undergoing a fundamental fork. One path continues 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 builds business structure first, letting Agents act on a clearly defined semantic map — they know boundaries, rules, and the basis for every decision step.

Short-term cost difference is small, but one year, three years later, the gap appears at every moment requiring regulatory explanation of decisions, every multi-system collaboration with semantic confusion, every critical node where an Agent "confidently does the wrong thing".

Enterprise AI competition is ultimately not between models, but who structures their business knowledge first . 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 remains — that is the reason to start now.