How Ontology‑Driven Agents Enable Controllable Execution in Harness Engineering

1. From the Agent hype to “uncontrollable”

In 2024‑2025 agents became the main form of enterprise AI, showing impressive demo performance but repeatedly failing in production because they lack a "structure that understands the rules"; they can execute tasks but do not know the boundaries of a specific industry or company.

2. Redefining the problem: “secure controllable” as a multi‑dimensional engineering proposition

The notion of secure controllable execution comprises several independent yet related dimensions:

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 tool‑calling stop? (Prompt constraints, whitelist, ontology modeling)

Audit & Traceability: What was done and can the decision process be reproduced? (Operation logs, decision‑chain tracing, explainability frameworks)

Exception Handling: How are errors degraded or rolled back? (Circuit‑breakers, human‑review nodes, idempotent design)

Result Validation: Does the output satisfy business rules? (Rule engine, formal verification, ontology‑based constraint checks)

Compliance Alignment: Does the process meet industry regulations? (Compliance knowledge base, approval‑flow integration, auditable reports)

The ontology‑driven solution focuses on the "Behavior Constraints" and "Result Validation" dimensions, providing a semantic infrastructure layer rather than a collection of ad‑hoc engineering tricks.

3. Architectural constraints: from an "added fence" to an "embedded skeleton"

Traditional engineering constraints work in simple scenarios but face three structural difficulties in complex business: rule explosion, natural‑language ambiguity, and implicit semantic relations. An ontology defines the agent’s action space from the start, turning constraints into a built‑in skeleton rather than an external fence. Rules are stored as queryable, verifiable structures instead of prompts, and tools are managed by the ontology layer, so the agent’s capabilities and triggers are dictated by the business model.

4. Context engineering: from "memory patching" to "re‑architecting memory"

Agents lose context in long tasks because information is stacked linearly as raw text. The ontology captures the business’s entities, relationships, and processes as a graph, allowing the cognition engine to extract a relevant semantic sub‑graph before execution. This yields three concrete improvements:

Precise Retrieval instead of Full Injection: Only the most relevant context is injected, preventing overflow and irrelevant interference.

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

Cross‑Task Reuse: The same semantic structure can serve multiple tasks, eliminating the need to rebuild context for each scenario.

The approach also bridges the gap between symbolic knowledge‑graph reasoning (deterministic but limited) and LLM reasoning (flexible but opaque) by applying deterministic ontology constraints where coverage exists and marking uncovered results with confidence scores.

5. Feedback loop: from subjective evaluation to traceable verification

Current feedback mechanisms rely on a secondary evaluator model, which can be fooled by superficially plausible outputs. The ontology enables objective verification: business rules are formalized and can be automatically checked against each agent output. Hard constraints (e.g., quota limits) are enforced directly, while soft constraints are combined with LLM assessment or human review.

The loop also drives continuous ontology evolution. Execution results that violate or expose gaps are fed back to the ontology, highlighting missing concepts, frequent error paths, and prompting targeted updates.

6. From technical controllability to business controllability – the Knora implementation path

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

Ontology Layer (Knowledge Base): Stored in a label‑property graph (LPG) with five core meta‑concepts – Entity, Relation, Event, Action, Logic – describing business objects, their connections, state changes, executable operations, and DAG‑based workflows.

Cognition Engine (Translation & Arbitration): Before an agent runs, it queries the ontology for the relevant sub‑graph (entities, rules, tools) and injects this structured context. After generation, the engine validates the result against the ontology and either accepts it or forces a re‑reasoning loop.

Execution Layer (Task Executor): The agent receives the enriched context, performs tool calls, and produces results. All tool usage, trigger conditions, and process flows are defined in the ontology, not in ad‑hoc prompts.

Data flow: User task → Cognition Engine extracts context → Agent reasons & executes → Result returns to Cognition Engine for ontology validation → Approved result is finally output.

Concrete work‑order change example

User requests to change work order WO‑2026‑0312 production quantity from 500 to 800.

Cognition Engine queries the ontology and finds the work order entity (type WorkOrder, status "issued/not started") and the attribute "change magnitude" = 60%.

The ontology defines a rule: changes >20% require approval ( requiresApproval = true).

Constraint check fails because the required approvedBy relation is missing.

System blocks the write, generates a structured error report, creates an approval task, and logs the intent with status "pending approval".

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

Automatic modeling and human‑in‑the‑loop

Cold‑starting a large‑scale ontology is costly; Knora adopts a layered, confidence‑driven approach. Highly structured tasks (e.g., mapping fields to ontology attributes, generating DAGs for data governance) are fully automated. Ambiguous semantic judgments receive a confidence score: high confidence executes automatically, medium confidence prompts human confirmation, low confidence routes to a review queue. Human feedback is fed back to improve future automation.

Real‑world deployments

Knora is already used in energy transport, electronics manufacturing, finance, and security. In a railway inspection scenario, a digital agent reduced a 30‑person, 7‑day manual reporting process to a 3‑person, 30‑minute automated workflow – a >70× efficiency gain. In electronics manufacturing, the platform replaces experience‑driven manual flows with knowledge‑driven automated pipelines for quality traceability and defect analysis.

Conclusion

Enterprise AI is at a crossroads: either continue stacking tools and prompts, leaving agents to act without clear boundaries, or first construct a business‑level semantic map and let agents operate on that map. The latter path incurs modest short‑term cost but yields a durable moat – a continuously evolving knowledge base that keeps agents accurate, auditable, and aligned with business objectives.