How Ontology‑Driven Agents Enable Controllable Execution in Harness Engineering
The article analyzes Harness Engineering’s semantic foundation, showing how an ontology‑driven approach restructures agent constraints, context handling, and feedback loops to achieve safe, auditable, and business‑level controllable execution, illustrated with a Knora implementation case study.
01 From the 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 real business, they often misuse terminology, deviate in reasoning, and produce results that conflict with corporate rules, effectively "confidently doing the wrong thing".
The root cause is not model weakness but the lack of a "rule‑aware structure"—agents know how to act but not the business boundaries or decision policies.
02 Redefining the Problem: "Safe and Controllable" Execution
Before proposing a solution, the article defines the dimensions of safe controllable execution, each with independent yet related concerns:
Permission & Isolation: Who can do what? Can data cross domains? – RBAC/ABAC, API gateways, data sandboxes
Behavior Constraints: Where does the agent’s reasoning and invocation stop? – Prompt constraints, tool whitelists, ontology modeling
Audit & Traceability: What was done? Can the decision process be reproduced? – Operation logs, decision‑chain tracing, explainability frameworks
Exception Handling: How to degrade or roll back on errors? – Circuit breakers, manual review nodes, idempotent design
Result Validation: Does the output meet business rules? – Rule engines, formal verification, ontology constraint checks
Compliance Alignment: Does it satisfy industry regulations? – Compliance knowledge base, approval flow integration, auditable reports
The focus of the ontology‑driven solution is on the "Behavior Constraints" and "Result Validation" dimensions, providing a semantic infrastructure layer rather than a replacement for existing engineering measures.
03 Architecture Constraints: From "External Fences" to "Built‑in Skeleton"
Traditional engineering constraints work in simple scenarios but face three structural challenges in complex business: rule explosion, natural‑language ambiguity, and implicit semantic links that hinder reuse.
Ontology changes the game by embedding constraints directly into the business structure. Rules are no longer external prompts but are defined as queryable, verifiable entities within the ontology. The agent’s execution intent is compared against the ontology after generation; violations trigger immediate rollback instead of silent passage.
04 Context Engineering: From "Memory Padding" to "Memory Reconstruction"
Agents lose context in long tasks, repeatedly asking for basic information or forgetting critical steps. The underlying issue is linear text stacking without structure.
Ontology models business data, processes, and relationships as a graph, enabling precise retrieval of relevant sub‑graphs before the agent starts reasoning. This replaces full‑context injection with targeted semantic sub‑graph injection, ensures consistency by managing outdated or conflicting information, and allows cross‑task reuse because the same semantic map serves multiple agents.
The approach also bridges symbolic reasoning and LLM inference: where the ontology covers a domain, it provides deterministic constraints; where it does not, the LLM fills the gap with confidence‑annotated results.
05 Feedback Loop: From "Subjective Evaluation" to "Traceable Verification"
Current feedback mechanisms rely on a model‑based evaluator, which can be fooled by superficially reasonable outputs and lacks business‑level judgment.
Ontology enables objective verification by formalizing business judgments (e.g., quota limits, prerequisite checks) as rules. Each agent output is automatically compared to these rules; violations are either blocked or routed to human review. Hard constraints are enforced directly, while soft constraints involve LLM assessment or manual audit.
The loop also drives ontology evolution: agents expose uncovered concepts and frequent error paths, prompting updates to the ontology, thus avoiding the static‑knowledge‑graph pitfall.
06 From Technical to Business Controllability – The Knora Path
Knora, the platform built by 悦点科技, materializes the methodology into a layered architecture:
Ontology Layer (Knowledge Base): Stored as a labeled‑property graph (LPG) with five core concepts—Entity, Relation, Event, Action, Logic—defining objects, connections, state changes, executable operations, and workflow orchestration.
Cognition Engine (Translation & Arbitration): Before agent execution, it extracts relevant knowledge (entities, relations, rules, tools) from the ontology and injects it into the agent’s context. After execution, it validates results against ontology constraints and either approves or forces re‑reasoning.
Agent Execution Layer: Receives user tasks, calls tools, and produces results, but all tool usage, triggers, and process flows are dictated by the ontology, not by ad‑hoc prompts.
Data flow: User task → Cognition Engine extracts relevant sub‑graph → Agent reasons and acts → Cognition Engine validates against ontology → If passed, result is committed; otherwise, error report is generated, approval task is created, and audit log records the intent.
A concrete work‑order change example demonstrates the full chain: the system blocks a 60% quantity increase that exceeds the 20% approval threshold, generates a structured error, creates an approval task, logs the intent, and after approval, re‑validates and writes the change.
Knora also addresses ontology boot‑strapping: automatic modeling handles high‑coverage, rule‑driven tasks (e.g., field‑to‑property mapping, DAG generation) with confidence scores; ambiguous cases are routed to human verification, and feedback continuously improves the model.
Real‑world deployments in energy transport, electronics manufacturing, finance, and security show dramatic efficiency gains (e.g., a rail inspection report generation reduced from 30 person‑days to a 3‑person‑hour workflow, >70× speedup).
07 Conclusion
Enterprise AI faces a fundamental fork: continue piling tools and prompts, or first build a structured business ontology that defines clear boundaries, rules, and decision provenance. The latter creates a self‑evolving semantic map that keeps agents accurate, auditable, and aligned with business goals, forming a lasting competitive moat beyond any single model or tool.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
DataFunSummit
Official account of the DataFun community, dedicated to sharing big data and AI industry summit news and speaker talks, with regular downloadable resource packs.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
