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

01 From Agent Hype to "Uncontrollable"

In 2024-2025, Agents became the primary form of enterprise AI deployment. These products can autonomously plan, invoke tools, and execute multi-step tasks, performing impressively in demos. However, in real business scenarios, problems are highly similar: inaccurate terminology, deviated reasoning logic, execution results misaligned with enterprise rules, and "confidently doing the wrong thing" at critical nodes.

The root cause is not insufficient model strength, but that Agents lack a "structure that understands the rules" — they know how to work but do not know the industry boundaries or the enterprise's decision rules. An executor who can work but barely understands the business is hard to trust with independent decisions.

This is the background for "Harness Engineering" becoming an industry buzzword in Q1 2026. Its core is not new: establish a complete constraint, feedback, and control system for Agents so they can act autonomously without deviating from business boundaries. The industry has formed three key technical pillars: architectural constraints to limit behavioral boundaries, context engineering to manage information input, and feedback loops to verify output quality.

Yet most practices remain at the engineering patching level — writing prompts, listing rules, building workflows, doing permission control. These work in simple scenarios but expose a deep issue in complex business: constraints are "externally added", semantics are "implicit", compliance relies on the model's understanding of rules, and that understanding is itself unreliable.

This article discusses a different path — using Ontology to provide semantic infrastructure for the Harness system, making constraints derive from business structure itself rather than engineering configuration. Ontology explicitly models business semantics, providing a unified structural foundation for the three technical pillars.

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

Before diving into solutions, we must clarify the boundaries of "safe and controllable execution." It comprises at least six interrelated but independent dimensions:

Permissions & Isolation : Who can do what? Can data cross boundaries? Engineering means: RBAC/ABAC, API gateways, data sandboxes.

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

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

Exception Handling : How to degrade and roll back when errors occur? Engineering means: Circuit breakers, human review nodes, idempotent design.

Result Verification : Does output comply with business rules? Engineering means: Rule engines, formal verification, ontology constraint validation.

Compliance Alignment : Does it meet industry regulatory requirements? Engineering means: Compliance knowledge bases, approval flow integration, auditable reports.

The ontology-driven solution primarily acts on Behavioral Constraints and Result Verification , with substantive contribution to Audit & Traceability . It is the semantic infrastructure layer of a complete safety system, not a replacement for other engineering means.

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

Engineering constraint methods work in simple scenarios but face three structural difficulties in complex business: rule count grows with business complexity, maintenance costs balloon; rules expressed in natural language create model understanding uncertainty and bypass risk; semantic relationships between rules and business objects are implicit, preventing cross-scenario reuse.

Ontology differs: it does not try to "block" the Agent but defines its behavioral space from the start. Constraints are not external fences but an internal skeleton built into the business structure.

The key mechanism: business rules are no longer natural language in prompts but explicitly modeled as queryable, verifiable structures. Tools are not ad-hoc defined at the Agent layer but uniformly managed by the ontology layer — what the Agent can use, how to trigger, and execution processes are all dictated by structure, not the model.

Constraint execution occurs after Agent output but before operation landing: the system retrieves the Agent's execution intent and compares it against the ontology. If predefined rules are violated, it is rejected for re-reasoning, never silently passed. Verification bases are traceable nodes and relationship paths in the structure; conclusions are deterministic, not dependent on model understanding.

04 Context Engineering: From "Patching 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. Whether introducing external memory, context compression, or extending window length, all essentially alleviate the same problem rather than solve it.

Ontology's entry point differs: enterprise data, processes, and relationships are inherently non-linear, a complex association network. Ontology makes these relationships explicit, building a queryable, evolvable business semantic network.

This structure brings three substantive improvements to context management:

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, controlling context overflow and irrelevant interference at the source.

Consistency Assurance : Business knowledge is managed by a unified semantic network; expired information, conflicts, and redundancies are systematically handled. The Agent always reasons on the latest consistent information, not relying on potentially outdated 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 graph reasoning is 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 supplement but conclusions are explicitly marked with confidence status. Each plays its role, preserving both accuracy and flexibility.

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

Mainstream feedback mechanisms introduce an "evaluator" model to judge model output. This has some effect but clear limitations — models are easily persuaded by superficially reasonable results and lack judgment on business-level correctness.

Ontology provides a more direct path: not relying on subjective evaluation but performing objective verification based on structure. Many enterprise judgments are essentially rule-based — whether exceeding quotas, satisfying preconditions, complying with process logic. These don't require "understanding" and can be directly verified. Once rules are incorporated into ontology, every Agent output can be automatically compared against business constraints, with binary pass/fail results.

Of course, 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, 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 knowledge graphs that are "built and left."

Explainability is another critical value. Every verification conclusion has explicit structural basis; every judgment traces to specific rule nodes and relationship paths. Regulatory audits need not "model thinks compliant" but "system can prove compliant." This gap is decisive in high-compliance industries like finance, manufacturing, and railways.

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

1. Constraints Come from Business Itself, Not Engineering Patching

If the methodology stays at principle level, significance is limited. The key is whether it's truly built and what essential change occurs in "controllability" after implementation.

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

The ontology-driven solution achieves something else: constraints come directly from business structure itself. Enterprise objects, relationships, rules are uniformly modeled as ontology; when executing tasks, the Agent doesn't just receive context and generate but must first enter this semantic layer, completing reasoning and decision-making within predefined business relationships. It's not free play but acting on a well-defined "business map."

This change brings three substantive shifts: Agents become participants with business semantics, not just execution tools; the system doesn't need per-scenario constraint reconstruction, reusing a unified semantic foundation; business rule layer remains 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 system architecture.

Ontology Layer (Knowledge Foundation) : Bottom layer stores ontology models in a Labeled Property Graph (LPG). At the meta-schema level, five core concepts are defined: 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 processes defined by a DAG orchestration engine).

The key design: traditional ontologies mainly solve "what is" classification problems, 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 the Agent can use, how to trigger, execution processes are all decided by ontology. This layer is the system's knowledge foundation, continuously evolvable.

Cognitive Engine Layer (Translation & Arbitration) : Bridges ontology and Agent, serving as translation and arbitration layer. Two core roles: (1) Before Agent startup, reads domain knowledge relevant to current scenario from ontology — including entity relationships, business rules, available tools — injecting into Agent's reasoning context, so the Agent knows both "how this domain operates" and "what tools I can use and how"; (2) After Agent generates results, retrieves conclusions for ontology constraint verification. If ontology-defined rules are violated, rejects back for re-reasoning.

Agent Execution Layer (Task Executor) : Autonomous intelligent product layer. Receives user tasks, invokes tools, generates results, completes execution. This layer is a pure executor — tool sources, usage, boundaries are 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 does not directly interact with Agent but exerts influence through the cognitive engine intermediate layer.

Manufacturing Example: "Work Order Output Change Requires Approval"

User intent: "Change work order WO-2026-0312 planned output 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:

Blocks direct write.

Generates structured error report carrying violated rule nodes and relationship paths.

Automatically creates approval task, routes to corresponding approvers.

Writes operation intent to audit log, status "Pending Approval".

After approval: Supplements approvedBy relationship, re-verification passes, executes write.

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

Enterprise ontology cold-start cost is an unavoidable reality. Manual construction of sufficiently covering ontologies traditionally takes weeks or months, requiring professional knowledge engineers.

Knora's strategy is not "fully automatic in one step" but layered processing, confidence-driven, human-machine collaboration fallback. Structured, pattern-clear tasks (e.g., field-to-ontology-attribute semantic mapping, auto-generating data governance DAG processes from ontology metadata) are automated; tasks involving business semantic judgment and concept boundary definition are not forced automated. 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 is precise, handling only truly ambiguous parts. Each human confirmation or correction feeds back into the system, continuously optimizing subsequent auto-modeling capability. As industry templates accumulate and domain samples adapt, human intervention ratio gradually decreases.

4. Actual Deployment Status

Knora currently has deployments in energy transportation, electronics manufacturing, finance, and security sectors.

Energy Transportation : 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 and Agent completing in 30 minutes — 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.

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

07 Conclusion

The way AI enters enterprises is undergoing a fundamental fork.

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

The short-term cost gap between the two paths is small, but the gap after one year, three years will manifest in every moment needing to explain decisions to regulators, every moment of semantic chaos in multi-system collaboration, every moment an Agent "confidently does the wrong thing" at a critical node.

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 precipitated in ontology will not — that is the reason to start now.