Ontology-Driven Agent Control: Semantic Foundations for Harness Engineering

Introduction: The Agent Control Problem

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 exhibit consistent failures: inaccurate terminology, reasoning drift, and misalignment with enterprise rules—“confidently doing the wrong thing” at critical nodes. The root cause is not insufficient model strength but the lack of a “structure that understands the rules”: the Agent knows how to act but not the industry boundaries or the enterprise’s decision rules.

Harness Engineering and Its Three Pillars

By 2026 Q1, “Harness Engineering” emerged as the industry term for building a complete constraint, feedback, and control system that lets Agents act autonomously without crossing 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-patching level—writing prompts, listing rules, assembling workflows, adding permission controls. These work in 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 own understanding of rules, which is itself unreliable.

Redefining “Safe and Controllable” as a Multi-Dimensional Engineering Proposition

Before proposing a solution, the article delineates six independent yet interrelated dimensions of safe, controllable execution:

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 conform to business rules? (Rule engines, formal verification, ontology constraint validation)

Compliance Alignment – Are industry regulatory requirements met? (Compliance knowledge bases, approval-flow integration, auditable reports)

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

Architecture Constraints: From “External Fences” to “Built-In Skeleton”

Engineering constraints face three structural difficulties in complex business: rule count grows with complexity, inflating maintenance cost; rules expressed in natural language leave model understanding uncertain and bypassable; semantic relationships between rules and business objects remain implicit, preventing cross-scenario reuse.

Ontology takes a different tack: instead of trying to “fence in” the Agent, it defines the Agent’s behavioral space from the outset. Constraints become an internal skeleton built into the business structure, not an external fence. Business rules are no longer natural-language snippets in prompts but explicitly modeled as queryable, verifiable structures. Tools are managed at the ontology layer, not the Agent layer—what tools exist, how they trigger, and what execution flows they follow are all dictated by structure, not by the model.

Constraint enforcement occurs after the Agent produces output but before the operation lands: the system retrieves the Agent’s execution intent and compares it against the ontology. If a rule is violated, the intent is rejected and the Agent must re-reason. The verification basis is a traceable node and relation path in the structure; the conclusion is deterministic and does not depend on model understanding.

Context Engineering: From “Supplementing Memory” to “Reconstructing How Memory Works”

Agents frequently “lose memory” in long tasks—repeatedly asking for basic information or dropping context at key nodes—because information is stacked as linear text without structure. External memory, context compression, and longer windows only mitigate the same problem rather than solving it.

Ontology recognizes that enterprise data, processes, and relationships are inherently a complex association network, not a linear stream. It makes those relationships explicit, building a queryable, evolvable business semantic network that delivers three concrete improvements:

Precise retrieval replaces full injection : Before the Agent starts, the cognitive engine extracts a task-relevant semantic subgraph from the ontology and dynamically injects only the most pertinent context, eliminating context overflow and irrelevant-noise interference at the source.

Consistency guarantee : Business knowledge lives in a unified semantic network where expired, conflicting, or redundant records can be systematically handled. The Agent always reasons on the latest consistent information, not on potentially stale prompt fragments.

Cross-task reuse : The same semantic structure serves different Agents across tasks, removing the need to reorganize context per scenario. The ontology is a continuously maintained “business map” on which Agents act, rather than starting from zero each time.

Additionally, ontology-driven context engineering bridges the long-standing divide between symbolic reasoning and LLM reasoning. Traditional knowledge-graph reasoning is explainable but coverage-limited; pure LLM reasoning is flexible but uncontrollable. Ontology provides a collaborative framework: where structure covers, it supplies deterministic constraints; where it does not, the LLM can fill in, but its conclusions are explicitly tagged with a confidence state. Each plays to its strength, 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 helps but has clear limits: models are easily persuaded by superficially plausible results and lack business-level correctness judgment.

Ontology offers a more direct path: objective verification based on structure, not subjective evaluation. A large portion of enterprise judgments are rule-checkable—whether a quota is exceeded, whether preconditions hold, whether process logic is followed. These do not require “understanding”; they can be directly verified. Once encoded in the ontology, every Agent output is automatically compared against business constraints, yielding a binary pass/fail.

Not all judgments can be formalized. “Hard constraints” suit ontology verification; “soft constraints”—whether a decision follows business convention, whether an operation hides abnormal motive, what constitutes a “major change”—do not. For soft constraints, the ontology approach combines with LLM evaluation or human-review nodes; the two complement rather than exclude each other.

The feedback loop also makes the ontology itself continuously evolve. The relationship is not one-way constraint: the ontology defines the Agent’s capability boundaries, while the Agent’s real-world execution touches massive business data that can feed back into the ontology—identifying uncovered concepts and relations, flagging frequent error paths in reasoning traces, and guiding ontology correction and iteration. This continuous-evolution loop is the core differentiator from traditional “build-once-and-forget” knowledge graphs.

Explainability is another critical value. Every verification conclusion has an explicit structural basis; every judgment traces to a specific rule node. Regulators need “the system can prove compliance,” not “the model thinks it’s compliant.” That gap is decisive in high-compliance domains such as finance, industrial control, and railways.

From Technical Control to Business Control: The Knora Implementation Path

1. Constraints from Business Itself, Not Engineering Patching

Traditional Harness solutions make Agents “more stable,” but stability is bounded by engineering: rules are hand-written, constraints configured, compliance maintained via prompts. The ceiling is clear—once business complexity exceeds engineering maintenance capacity, constraints fail.

Ontology-driven Harness achieves a different outcome: constraints derive directly from business structure. Enterprise objects, relations, and rules are unified into an ontology. When executing a task, the Agent does not simply receive context and generate; it must first enter this semantic layer and reason and decide within the predefined business relations. It operates on a well-defined “business map,” not in free play.

This shift yields three substantive transformations: the Agent becomes a business-semantic participant rather than a mere tool executor; the system reuses a single semantic foundation across scenarios instead of rebuilding constraints per scenario; and the business-rules layer remains stable while model versions iterate. This is the leap from “technical control” to “business control.”

2. Knora’s Layered System Architecture

悦点科技’s Knora platform materializes the above methodology as a three-layer collaborative architecture.

Ontology Layer (Knowledge Base)

The base layer stores the ontology model in a Labeled Property Graph (LPG). At the meta-schema level it defines five core concepts:

Entity – business objects (e.g., work orders, equipment, personnel)

Relation – semantic connections between entities

Event – meaningful state changes in the business

Action – system-executable operations, including trigger conditions and parameter constraints

Logic – execution flows defined by a DAG orchestration engine

The key innovation: traditional ontology addresses “what is” classification; Action and Logic turn ontology from static knowledge description into an executable business specification that directly drives Agent tool calls and process orchestration. Tools are defined at the ontology layer, not the Agent layer—the Agent’s available tools, triggers, and flows are all decided by the ontology. This layer is the system’s knowledge foundation and evolves continuously.

Cognitive Engine Layer (Translation & Arbitration)

Sitting between ontology and Agent, this layer bridges the two. Its two core functions:

Before Agent startup, it reads domain knowledge from the ontology—entity relations, business rules, available tools—and injects them into the Agent’s reasoning context, so the Agent knows both “how this domain operates” and “which tools I can use and how.”

After the Agent generates a result, the engine verifies the conclusion against ontology constraints. If a rule is violated, it rejects the result and forces the Agent to re-reason.

Agent Execution Layer

The autonomous intelligent-agent product layer. It receives user tasks, invokes tools, and produces results. It is a pure executor: tool provenance, usage, and boundaries are not self-determined but defined by the ontology layer and passed via the cognitive engine.

Data Flow

User task → Cognitive engine extracts relevant knowledge from ontology and injects context → Agent reasons and executes in that context → Result returns to cognitive engine for ontology verification → Output only after passing. The ontology never interacts directly with the Agent; it acts through the cognitive engine intermediary.

Worked Example: Manufacturing Work-Order Quantity Change

Business rule: “Work-order quantity changes require approval.”

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 the ontology-defined 20% approval threshold.

Action rule: over-threshold change triggers requiresApproval = true.

Relation chain:

WorkOrderChange → approvedBy → [BOMEngineer, ProductionManager]

.

Constraint verification : Current operation lacks the approvedBy relation; verification fails.

System response :

Block direct write.

Generate structured error report carrying the violated rule node and relation path.

Auto-create approval task routed to the designated approvers.

Write operation intent to audit log with status “pending approval.”

After approval : Add approvedBy relation, re-verify (now passes), execute write.

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

Enterprise ontology cold-start cost is a practical hurdle—manual construction of a sufficiently comprehensive ontology traditionally takes weeks or months and requires dedicated knowledge engineers. Knora does not pursue “fully automatic in one step” but adopts layered, confidence-driven, human-in-the-loop fallback. Structured, regular tasks (e.g., field-to-ontology-attribute semantic mapping, auto-generating data-governance DAG flows from ontology metadata) are automated. Tasks involving business-semantic judgment or concept-boundary delineation are not forced into automation. The system assigns a confidence score to each auto-generated result: high confidence → auto-execute; medium → recommend human confirmation; low → route to review queue. Human intervention is precisely targeted at truly ambiguous parts. Every human confirmation or correction feeds back to improve subsequent auto-modeling; as industry templates accumulate and domain samples adapt, the human-intervention ratio steadily declines.

4. Production Deployments

Knora is live in energy transport, electronics manufacturing, finance, and security domains.

Energy transport : A railway comprehensive inspection report generation Agent auto-constructs indicator systems and generates reports. Work that previously required 30 people over 7 days now takes 3 people one day to verify data plus 30 minutes of Agent automation —a 70× efficiency gain . Dozens of scenarios—safety-hazard identification, maintenance-plan generation, emergency-plan generation, emergency-resource scheduling—now run as “digital employees” performing actual business duties.

Electronics manufacturing : Core scenarios such as quality traceability and defect analysis have shifted from experience-dependent manual processes to precise knowledge-driven automated digital business flows.

Conclusion

AI’s entry into the enterprise is at a fundamental fork. One path keeps stacking tools, prompts, and integrations—Agents run, but no one truly knows where they go or what they produce. The other path builds the business structure first, letting Agents act on a clearly defined semantic map—knowing the boundaries, the rules, and the basis for every decision.

Short-term cost difference is small, but the gap after one or three years will appear at every moment a regulator demands a decision explanation, at every multi-system collaboration where semantic chaos erupts, and at every critical node where an Agent “confidently does the wrong thing.”

Enterprise AI competition is ultimately not model versus model, but who structures their business knowledge first . Organizations that close this loop first accumulate not just a system but a continuously self-evolving business intelligence foundation—one that grows more accurate with every Agent execution and more complete with every business iteration.

The real moat is never a purchased tool; it is precipitated cognition. Agents will be replaced, models will be iterated, but the business cognition embedded in the ontology remains. That is the reason to start now.