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

Problem Statement

From 2024‑2025, enterprise AI agents demonstrate strong performance in demos but often fail in production because they lack a rule‑aware structure that defines industry boundaries and business decision rules. The root cause is not model weakness but the absence of a semantic skeleton that constrains agent reasoning and actions.

Multi‑Dimensional Definition of Safe and Controllable Execution

Safe execution comprises several independent but related dimensions:

Permission & Isolation : Who can do what and whether data may cross domains. Engineering means include RBAC/ABAC, API gateways, data sandboxes.

Behavioral Constraints : Limits on an agent’s reasoning and tool usage. Engineering means include prompt constraints, tool whitelists, ontology modeling.

Audit & Traceability : Recording what was done and reproducing the decision process. Engineering means include operation logs, decision‑chain tracing, explainability frameworks.

Exception Handling : Degrading or rolling back on errors. Engineering means include circuit‑breakers, human‑review nodes, idempotent design.

Result Validation : Ensuring outputs satisfy business rules. Engineering means include rule engines, formal verification, ontology constraint checks.

Compliance Alignment : Meeting industry regulatory requirements. Engineering means include compliance knowledge bases, approval‑flow integration, auditable reports.

The ontology‑driven approach focuses on the Behavioral Constraints and Result Validation dimensions, providing a semantic infrastructure layer rather than a collection of ad‑hoc engineering glue.

Architecture Constraints: From External Fences to Built‑In Skeletons

Traditional engineering constraints work in simple scenarios but encounter three structural challenges in complex business:

Rule explosion as business complexity grows.

Ambiguous natural‑language expressions that models may misinterpret.

Implicit semantic relations that cannot be reused across contexts.

Ontology changes the paradigm by defining the agent’s action space within the business structure itself. Constraints become intrinsic to the ontology; after an agent generates an intent, the system compares it against the ontology and rolls back deterministically on violations.

Context Engineering: From Memory Padding to Reconstructing Memory

Agents often lose context in long tasks because information is stored linearly as text. An ontology provides a queryable semantic graph; before agent activation the cognitive engine extracts the relevant sub‑graph and injects only the necessary context. This yields precise retrieval, consistency across steps, and cross‑task reuse.

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

Feedback Loop: From Subjective Evaluation to Traceable Verification

Typical feedback mechanisms rely on a secondary evaluator model, which can be fooled by superficially plausible outputs. The ontology offers an objective, rule‑based verification step: every business judgment (e.g., quota limits, prerequisite checks) can be formalized and automatically compared against the agent’s output.

Hard constraints are verified directly; soft constraints combine ontology checks with LLM or human review. The loop also enables continuous ontology evolution: agents expose uncovered concepts and frequent error paths, guiding ontology refinement.

Knora Implementation Path

1. Layered System Architecture

Ontology Layer (Knowledge Base) : Stores the ontology in a label‑property graph (LPG) with five core concepts—Entity, Relation, Event, Action, Logic—each defining business objects, their connections, state changes, executable operations, and workflow orchestration.

Cognitive Engine Layer (Translation & Arbitration) : Before agent launch, extracts relevant knowledge (entities, rules, tools) from the ontology and injects it into the agent’s reasoning context. After generation, validates results against the ontology and forces re‑reasoning on violations.

Agent Execution Layer : Receives user tasks, calls tools, and produces results, but all tool usage, triggers, and process flows are dictated by the ontology.

2. Data Flow

User Task → Cognitive Engine extracts knowledge → Agent reasons within that context → Result returns to Cognitive Engine for ontology validation → If passed, output is emitted; otherwise the agent is blocked, an error report is generated, and an approval task is created.

3. Automatic Modeling with Human‑in‑the‑Loop

Cold‑starting a large‑scale ontology is costly. Knora adopts a confidence‑driven approach: high‑confidence automatic mappings are executed directly, medium‑confidence suggestions require human confirmation, and low‑confidence items go to a review queue. Human corrections feed back to improve future automation.

4. Real‑World Deployments

Knora has been applied in energy transport, electronics manufacturing, finance, and security. In a railway inspection scenario, a manual 30‑person/7‑day reporting process was reduced to a 3‑person, 30‑minute automated workflow (>70× efficiency gain). In electronics manufacturing, quality‑traceability and defect‑analysis pipelines were transformed from experience‑driven manual steps to precise, knowledge‑driven digital flows.

5. Example: Work‑Order Production Change

Scenario: Change the planned production quantity of work order WO-2026-0312 from 500 to 800.

Agent receives the user intent.

Cognitive engine queries the ontology (LPG traversal) and retrieves the work‑order node (type WorkOrder, status “issued/not started”) and the attribute “change percentage”. The requested change (60%) exceeds the ontology‑defined approval threshold (20%).

Ontology defines an Action rule: requiresApproval = true for changes above the threshold.

Constraint validation fails because the required approvedBy relationship is missing.

System response: block the write, generate a structured error report with the violated rule node and relationship path, automatically create an approval task routed to the designated approvers, and log the intent with status “pending approval”.

After approval, the approvedBy relationship is added, the constraint passes, and the work‑order update is committed.

Conclusion

Enterprise AI faces a choice: continue stacking prompts and tools, or first construct a semantic business skeleton that guides agents. An ontology‑driven skeleton yields a self‑evolving, auditable, business‑aligned intelligence layer that remains stable across model upgrades and provides deterministic control over agent behavior.