Harness Engineering’s Semantic Foundation: Ontology‑Driven, Controllable Agents

1. From Agent Hype to “Uncontrollable”

In 2024‑2025 agents become the main form of enterprise AI, capable of planning, tool use, and multi‑step execution. In demo environments they shine, but in real business they frequently misuse terminology, drift in reasoning, and produce results that violate company policies, essentially “confidently doing the wrong thing.” The root cause is not model weakness but the lack of a “rule‑aware structure” that tells the agent where the business boundaries lie.

2. Redefining “Safe Controllable Execution” as a Multi‑Dimensional Engineering Problem

The author decomposes the problem into independent yet related dimensions, each with concrete engineering means:

Permission & Isolation : Who can do what and whether data may cross domains – addressed by RBAC/ABAC, API gateways, and data sandboxes.

Behavior Constraints : Limits on the agent’s reasoning and tool calls – enforced through prompt constraints, whitelist of tools, and ontology modeling.

Audit & Traceability : Recording what was done and whether decisions can be reproduced – achieved with operation logs, decision‑chain tracking, and explainability frameworks.

Exception Handling : How to degrade or roll back on errors – implemented via circuit breakers, human‑review nodes, and idempotent designs.

Result Verification : Whether outputs satisfy business rules – performed with rule engines, formal verification, and ontology‑based constraint checks.

Compliance Alignment : Meeting industry regulatory requirements – supported by compliance knowledge bases, approval‑flow integration, and auditable reports.

The ontology‑driven approach focuses on the “Behavior Constraints” and “Result Verification” dimensions, providing a semantic infrastructure layer rather than replacing other engineering techniques.

3. Architecture Constraints: From External Fences to Built‑In Skeleton

Traditional engineering constraints work in simple scenarios but face three structural difficulties in complex business: rule explosion, ambiguous natural‑language rules, and implicit semantic relations that hinder reuse. Ontology changes the paradigm: instead of adding external fences, the agent’s action space is defined inside the business structure itself. Rules are stored as queryable, verifiable structures rather than as prompts, and tools are managed by the ontology layer. Constraint enforcement occurs after the agent generates an intent but before execution; any violation triggers a deterministic rollback based on explicit ontology nodes.

4. Context Engineering: From “Memory Patch” to “Re‑Constructing Memory”

Long‑running tasks suffer from “forgetting” because context is a linear text stack. Adding external memory or extending windows only mitigates the symptom. Ontology provides a graph‑based business semantic network that can be queried for the most relevant sub‑graph before the agent starts reasoning. This yields three concrete improvements:

Precise Retrieval Instead of Full Injection : Only the most relevant semantic sub‑graph is injected, eliminating overflow and irrelevant noise.

Consistency Assurance : A unified semantic network resolves stale, conflicting, or redundant information, ensuring the agent always reasons on the latest consistent data.

Cross‑Task Reuse : The same semantic structure serves multiple tasks, so the agent operates on a continuously maintained “business map” rather than rebuilding context each time.

The ontology also bridges symbolic knowledge‑graph reasoning (deterministic but limited) with LLM reasoning (flexible but opaque). Where the ontology covers a concept, it enforces deterministic constraints; where it does not, the LLM fills the gap with a confidence label.

5. Feedback Loop: From Subjective Evaluation to Traceable Verification

Current feedback loops rely on a “critic” model that judges the output, which easily gets fooled by superficially plausible results and lacks business‑level judgment. Ontology enables direct, objective verification: many business decisions can be formalized as rules (e.g., amount limits, prerequisite checks). Each agent output is automatically compared against these rules; the result is either accepted or rejected with a clear, traceable reason.

Hard constraints (e.g., exceeding a numeric threshold) are fully automated, while soft constraints (e.g., business conventions) are combined with LLM evaluation or human review, forming a complementary loop. The loop also drives ontology evolution: failed paths highlight uncovered concepts, prompting updates to the ontology.

6. From Technical Controllability to Business Controllability – The Knora Implementation Path

Knora, the platform built by 悦点科技, materializes the methodology in a layered architecture:

Ontology Layer (Knowledge Base) : Stores the ontology as a label‑property graph (LPG). Core meta‑model concepts include Entity, Relation, Event, Action, and Logic (DAG‑based workflow).

Cognition Engine (Translation & Arbitration) : Before agent execution, it extracts the relevant sub‑graph (entities, relations, rules, tools) and injects it into the agent’s reasoning context. After generation, it validates the result against the ontology and either approves or forces a re‑reasoning step.

Agent Execution Layer : Receives user tasks, calls tools, and produces results. All tool usage, triggers, and process flows are dictated by the ontology, not by ad‑hoc prompts.

Data flow: User task → Cognition Engine queries ontology → Context injected into Agent → Agent reasons & executes → Result returned to Cognition Engine for ontology validation → If passed, final output is emitted.

Concrete work‑order change example (WO‑2026‑0312):

User intent: change planned production from 500 to 800.

Cognition Engine queries the ontology graph and retrieves the work‑order entity, its current status, and the “change‑percentage” attribute (60%).

Constraint check discovers that 60% exceeds the ontology‑defined approval threshold of 20%.

System response blocks direct write‑back, generates a structured error report with the violated rule node, and creates an approval task routed to the designated approvers.

After approval, the missing approvedBy relation is added, the constraint passes, and the change is persisted.

Knora’s automatic modeling strategy reduces the cold‑start cost of enterprise ontologies by combining high‑confidence automated mapping for obvious structures with human‑in‑the‑loop verification for ambiguous semantic judgments. Confidence scores dictate whether a result is executed directly, suggested for manual confirmation, or sent to an audit queue.

7. Conclusion

Enterprise AI faces a fundamental fork: continue stacking prompts and tools, or first construct a business‑level semantic map that tells agents where the boundaries are, what the rules are, and why each decision is made. The latter path—embodied by Harness Engineering’s ontology‑driven, controllable agents—creates a self‑evolving business intelligence base that outlives model updates and becomes a lasting competitive moat.