Ontology-Driven Agent Control: The Semantic Foundation of Harness Engineering

01 From Agent Hype to "Uncontrollable"

In 2024‑2025, Agents became the primary form of enterprise AI deployment. They can plan autonomously, call tools, and execute multi‑step tasks, shining in demos. However, in real business they misuse terminology, deviate in reasoning, and produce results that 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." Agents know how to work but not the industry boundaries or the enterprise's decision rules. This gap drives the 2026 Q1 rise of "Harness Engineering": building a complete constraint, feedback, and control system so Agents act autonomously yet stay within business boundaries. The industry has converged on three pillars: architectural constraints to bound behavior, context engineering to manage information input, and feedback loops to verify output quality.

Most practices remain at the engineering‑patch level — writing prompts, listing rules, wiring workflows, adding permission controls. These work for 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.

This article proposes 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 structured foundation for the three pillars.

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

Before diving into solutions, the article clarifies the dimensions of "safe and controllable execution" via a table:

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 substantial contribution to Audit & Traceability . It serves as the semantic infrastructure layer within a complete safety system, not a replacement for other engineering measures.

03 Architectural Constraints: From "External Fence" to "Internal Skeleton"

Engineering constraints face three structural difficulties in complex business: rule count explodes with complexity, natural‑language rules introduce model‑understanding uncertainty and bypass risk, and semantic relationships between rules and business objects remain implicit, preventing cross‑scenario reuse.

Ontology differs by defining the Agent's behavior space upfront. Constraints become an internal skeleton built into the business structure, not an external fence. Business rules are explicitly modeled as queryable, verifiable structures instead of living in prompts. Tools are managed at the ontology layer — what an Agent can use, how it triggers, and the execution flow are all dictated by structure, not the model.

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.

04 Context Engineering: From "Supplementing Memory" to "Restructuring Memory"

Agents frequently "lose memory" in long tasks — repeatedly asking for basic information or losing context at key nodes — because information is stacked as linear text without structure. Adding external memory, compressing context, or extending window length only alleviates the symptom.

Ontology treats enterprise data, processes, and relationships as an explicit, queryable, evolvable semantic network. This brings three concrete improvements:

Precise Retrieval Replaces Full Injection : Before Agent startup, the cognitive engine extracts a task‑relevant semantic subgraph from the ontology and dynamically injects only the most relevant context, eliminating overflow and noise.

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

Cross‑Task Reuse : The same semantic structure serves different Agents across tasks, avoiding per‑scenario context reconstruction. The ontology is a continuously maintained "business map" on which Agents act.

Ontology‑driven context engineering also bridges the split between symbolic reasoning (explainable but limited coverage) and LLM reasoning (flexible but uncontrollable). Where structure covers, ontology gives deterministic constraints; where it doesn't, LLM fills in with explicit confidence tags. Both play to their strengths.

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

Mainstream feedback uses an "evaluator" model to judge another model's output. This has limited effect because models are easily persuaded by superficially plausible results and lack business‑level correctness judgment.

Ontology enables objective verification against structure. Many enterprise judgments are rule‑based — quota limits, pre‑condition satisfaction, process logic — and can be verified directly without "understanding." Once encoded in ontology, every Agent output is automatically compared against business constraints; the result either holds or fails.

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

The feedback loop also makes the ontology self‑evolving. Ontology defines Agent boundaries; Agent execution touches massive business data, which feeds back to identify uncovered concepts/relations, flag frequent error paths, and guide ontology refinement. This continuous evolution distinguishes it from static knowledge graphs.

Explainability is another key value: every verification conclusion has explicit structural evidence, traceable to specific rule nodes. Regulators need "system can prove compliance," not "model thinks it's compliant" — a decisive gap in finance, industry, railway, and other strong‑compliance sectors.

06 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" 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 lets constraints originate from business structure. Enterprise objects, relations, and rules are uniformly modeled as ontology; Agents must enter this semantic layer before reasoning, acting within a predefined "business map." This yields three shifts: Agents become semantic participants, not mere tools; constraints reuse across scenarios on a unified semantic foundation; business rules stay stable across model iterations. 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 Base) : 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 links), Event (meaningful state changes), Action (executable operations with trigger conditions and parameter constraints), and Logic (execution flows orchestrated by a DAG engine). Crucially, Action and Logic turn ontology from static description into executable business specifications that directly drive Agent tool calls and process orchestration. Tools are defined at the ontology layer, not the Agent layer.

Cognitive Engine Layer (Translation & Arbitration) : Bridges ontology and Agent. Before Agent startup, it reads domain knowledge (entity relations, business rules, available tools) from ontology and injects into the Agent's reasoning context. After Agent generates results, it verifies conclusions against ontology constraints; violations trigger re‑reasoning.

Agent Execution Layer : Pure executor. Receives user tasks, calls tools, produces results. Tool availability, usage, and boundaries are defined by ontology and delivered via the cognitive engine.

Data flow: User task → Cognitive engine extracts relevant knowledge from ontology → Agent reasons/executes in that context → Results return to cognitive engine for ontology verification → Output only after passing. Ontology never interacts directly with Agent; the cognitive engine mediates.

Case Study: Manufacturing Work‑Order Quantity Change

Scenario: "Change work order WO‑2026‑0312 planned quantity from 500 to 800."

User intent captured.

Cognitive engine queries ontology (LPG graph traversal):

Node: WO‑2026‑0312, type WorkOrder, state "Issued/Not Started".

Attribute: Change magnitude 60%, exceeding the 20% approval threshold defined in ontology.

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 node and relation path.

Auto‑creates approval task routed to designated approvers.

Logs operation intent in audit log with status "Pending Approval".

After approval: approvedBy relation added, re‑verification passes, write executed.

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

Enterprise ontology cold‑start cost is a real challenge. Knora avoids "fully automatic in one step" in favor of layered, confidence‑driven, human‑in‑the‑loop approach. Structured, regular tasks (field‑to‑ontology attribute mapping, auto‑generating data‑governance DAGs from ontology metadata) are automated. Tasks requiring business semantic judgment or concept boundary definition are not forced. Each auto‑generated result receives a confidence score: high confidence executes directly, medium confidence recommends human confirmation, low confidence enters review queue. Human interventions are precise, targeting only ambiguous parts. Each confirmation/correction feeds back to improve subsequent automation; as industry templates accumulate and domain samples adapt, human intervention ratio declines.

4. Real‑World Deployment

Knora has landed in energy transport, electronics manufacturing, finance, and security domains.

Energy Transport : Railway comprehensive inspection report generation Agent automatically builds indicator systems and generates reports. Work that took 30 people 7 days becomes 1 person day for data review + 30 minutes Agent auto‑completion — over 70× efficiency gain. Deployed as "digital employees" in dozens of scenarios: safety hazard identification, maintenance planning, emergency plan generation, emergency resource dispatch.

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

07 Conclusion

Enterprise AI adoption is diverging fundamentally. One path keeps stacking tools, prompts, and integrations — Agents run but no one knows where or what they'll produce. The other builds business structure first, letting Agents act on a clearly defined semantic map — they know boundaries, rules, and the rationale for every decision.

Short‑term cost difference is small, but after one or three years the gap appears at every regulatory explanation moment, every multi‑system 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 . Companies that close this loop early accumulate not just a system but a continuously self‑evolving business intelligence foundation — growing more accurate with each Agent execution, more complete with each business iteration.

The real moat is never bought tools, but沉淀下来的认知 (precipitated cognition). Agents will be replaced, models will iterate, but the business cognition solidified in ontology remains — the reason to start now.