Ontology-Driven Agent Control: Semantic Foundations for Harness Engineering

From Agent Hype to "Uncontrollable" Reality

In 2024-2025, AI agents became the primary form of enterprise AI deployment. While impressive in demos — autonomously planning, calling tools, and executing multi-step tasks — they fail in real business contexts: misusing terminology, deviating in reasoning, and producing results that violate enterprise rules, often "confidently doing the wrong thing" at critical nodes.

The root cause is not model capability but the lack of a "structure that understands 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: architectural constraints to limit behavioral boundaries, context engineering to manage information input, and feedback loops to verify output quality.

Most implementations remain at the engineering patchwork level: writing prompts, listing rules, building workflows, adding permission controls. These work for simple scenarios but expose a deep structural problem in complex business: constraints are "externally added," semantics are "implicit," and compliance relies on the model's unreliable understanding of rules.

This article presents a different path: using ontology as the semantic infrastructure for Harness Engineering, making constraints derive from business structure itself rather than engineering configuration. Ontology explicitly models business semantics, providing a unified structural foundation for the three pillars.

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

Before detailing the solution, the article clarifies the dimensions of "safe and controllable execution" via a table:

Permissions & 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.

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

Engineering constraints face three structural difficulties in complex business: rule count grows with complexity (maintenance cost explodes), rules expressed in natural language create model understanding uncertainty (bypass risk), and semantic relationships between rules and business objects are implicit (no cross-scenario reuse).

Ontology differs by not trying to "block" the agent but defining its behavioral space from the start. Constraints become an internal skeleton built into business structure, not an external fence.

Key mechanism: business rules are no longer natural language in prompts but explicitly modeled as queryable, verifiable structures. Tools are managed uniformly at the ontology layer — not ad-hoc at the agent layer. What agents can use, how to trigger, and execution flows are 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 trigger immediate rejection with deterministic conclusions based on traceable nodes and relationship paths, not model understanding.

Context Engineering: From "Supplementing Memory" to "Restructuring 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, and window expansion only alleviate, not solve.

Ontology recognizes that enterprise data, processes, and relationships are inherently a complex association network. It makes this network 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 — eliminating 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. Agents always reason 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 (explainable but limited coverage) and LLM reasoning (flexible but uncontrollable). The ontology provides a collaboration framework: where structure covers, it gives deterministic constraints; where it doesn't, LLM supplements with explicitly marked confidence status. Both maintain their roles — preserving 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 limits: models are easily persuaded by superficially plausible results and lack business-level correctness judgment.

Ontology enables a more direct path: objective verification based on structure, not subjective evaluation. Many enterprise judgments are rule-verifiable — quota exceedance, precondition satisfaction, process logic compliance. These need no "understanding," just verification. Once encoded in ontology, every agent output is automatically compared against business constraints with binary pass/fail results.

Not all judgments are formalizable. "Hard constraints" suit ontology verification; "soft constraints" (business conventions, abnormal motives, "major change" definitions) require LLM evaluation or human review — complementary, not mutually exclusive.

Another feedback value: continuous ontology evolution. The ontology-agent relationship is not one-way constraint. Agents encounter massive business data during execution, which feeds back to the ontology — identifying uncovered concepts and relationships, flagging frequent reasoning error points, guiding ontology correction and iteration. This continuous evolution loop distinguishes it from static "build-and-forget" knowledge graphs.

Explainability is critical: every verification conclusion has explicit structural basis; every judgment traces to specific rule nodes. Regulatory audits need "system can prove compliance," not "model thinks it's compliant." This gap is decisive in strong-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: when business complexity exceeds engineering maintenance capacity, constraints fail.

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

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 across model iterations, avoiding version drift. This is the leap from "technical control" to "business control."

2. Knora's System Architecture

YueDian Technology's Knora platform implements this methodology as a layered collaborative architecture.

Ontology Layer (Knowledge Foundation)

Bottom layer stores ontology models in a Labeled Property Graph (LPG) . The meta-schema defines five core concepts:

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 a DAG orchestration engine.

Crucially, traditional ontologies address "what is" classification, while Action and Logic transform ontology from static knowledge description into executable business specifications that directly drive agent tool invocation and process orchestration. Tools are defined at the ontology layer, not the agent layer — what tools agents can use, how to trigger, and execution flows are all ontology-determined. This layer is the system's knowledge foundation, continuously evolvable.

Cognitive Engine Layer (Translation & Arbitration)

Bridges ontology and agent. Two core functions:

Pre-startup: reads domain knowledge relevant to the current scenario from ontology — entity relationships, business rules, available tools — and injects into the agent's reasoning context, so the agent knows both "how this domain operates" and "which tools I can use and how."

Post-generation: retrieves agent conclusions and verifies against ontology constraints. Violations trigger re-reasoning.

Agent Execution Layer (Task Executor)

Autonomous intelligent agent product layer. Receives user tasks, invokes tools, generates results. Pure executor — tool sourcing, usage, boundaries are not self-determined but defined by ontology layer and transmitted 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 verified outputs are finally emitted. Ontology never interacts directly with agent; the cognitive engine mediates.

Manufacturing Example: Work Order Quantity Change Requires Approval

Complete 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, 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]

.

Constraint Verification : Current operation lacks approvedBy relationship → verification fails.

System Response :

Block direct write.

Generate structured error report with specific violated rule nodes and relationship paths.

Auto-create approval task routed to corresponding approvers.

Write operation intent to audit log with status "Pending Approval".

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

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

Enterprise ontology cold-start cost is a real challenge. Manual construction of high-coverage ontologies traditionally takes weeks/months with professional knowledge engineers.

Knora's strategy: not "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) are automated. Tasks involving business semantic judgment and concept boundary definition are not forced. System assigns confidence scores to each auto-generated result: high confidence → direct execution; medium → recommend human confirmation; low → review queue. Human intervention targets only truly ambiguous parts. Each human confirmation/correction feeds back to continuously optimize subsequent auto-modeling. 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, electronics manufacturing, finance, and security.

Energy Transport : Railway comprehensive inspection report generation agent automatically constructs indicator systems and generates reports. Original 30 people / 7 days to organize data and write reports → 3 people for one day data verification + agent 30 minutes auto-completion. Efficiency improvement >70x. Deployed as "digital employees" across dozens of scenarios: safety hazard identification, maintenance plan generation, emergency plan generation, emergency resource scheduling.

Electronics Manufacturing : Core scenarios like quality traceability and defect analysis transformed from experience-dependent manual processes into precision-knowledge-driven automated digital business flows.

Conclusion

Enterprise AI adoption is fundamentally bifurcating. One path: keep stacking tools, accumulating prompts, doing integrations — agents run but no one knows where they'll go or what they'll produce. The other: first build business structure, let agents act on a clearly defined semantic map — they know boundaries, rules, and the basis for every decision.

Short-term cost difference is small, but the gap after one or three years 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 iterate, but business cognition沉淀 in ontology will not — that's why it's worth starting now.