Data, Logic, Action: The Ontology Stack Every Enterprise Agent Needs

Part 2 of 3 in the Enterprise Ontology series. Part 1 covered the failure mode. This part covers the architecture.

Most enterprise ontology debates start in the wrong place. The question is not whether the model looks elegant. The question is whether agents can use it to act.

Most enterprise data architecture was built for a job AI agents do not have: producing reports for humans to read. Tables, columns, dashboards, and SQL queries all assume a human at the end of the pipeline, someone who supplies the missing context from experience. Agents can't do that. They need the context written down.

That gap is what the ontology layer fills. To see why, start with the architectural shift it implies.

From data tables to business objects

A traditional analytics stack answers "what is in this table?" An agentic stack has to answer a longer list:

• What business object does this row represent?
• Is this the same entity as the one in the other system?
• What relationships matter for this decision?
• What rules apply before I act?
• Which system should I write back to?
• What evidence do I record for audit?

The shift is from rows to objects:

Traditional Data Architecture	Agentic Ontology Architecture
Tables and columns	Business objects with typed properties
Static rows	Entities with relationships and states
SQL queries	Object-level reasoning and governed actions
Documentation-based rules	Explicit constraints and policies
Siloed source systems	Unified semantic layer
Human interpretation	Machine-interpretable business context

The right-hand column is what an agent needs. The left-hand column is what most companies have.

The three-layer stack: data, logic, action

Underneath any production agent are three layers, whether you name them or not.

Data is the current state of the business: inventory levels, customer accounts, open orders, supplier records, trade positions, contracts, invoices, tickets. The systems of record. This layer already exists at most companies.

Logic answers how the business should reason about that state: business rules, regulatory constraints, eligibility checks, entity resolution, operational policies. This is the layer that's usually scattered, half in code, half in PDFs, half in someone's head. The ontology lives here.

Action covers what the agent does about that state: write-backs to an Enterprise Resource Planning (ERP) system, updates to a Customer Relationship Management (CRM) record, filings, support cases, inventory movements, workflow approvals, human review.

Every agent that takes action traverses all three layers. Most teams build the data layer and the action layer, then assume a Large Language Model (LLM) will handle the logic layer through prompts. That is the gap that produces the failures from Part 1.

Where ontology fits in the agent control plane

Ontology is one piece of a broader control plane, alongside retrieval, semantic modeling, reasoning, validation, policy enforcement, tool mediation, observability, and human review.

The ontology is the semantic substrate. It doesn't make the LLM deterministic or enforce every constraint by itself. It gives every other layer a shared business meaning to operate on.

That boundary matters. The ontology tells the system what a Supplier, Invoice, Legal Entity, Purchase Order, and Approval Policy mean. The policy engine decides whether the agent can act. The validation layer checks the proposed action. The execution and tool mediation layer controls the API call. The audit layer records the evidence.

Without the ontology, each layer invents its own meaning.

When the agent proposes "approve this supplier payment," the ontology lets the system interpret:

• What kind of supplier is this?
• Which legal entity is paying?
• Which contract governs the payment?
• Is the invoice tied to a valid purchase order?
• Is the amount above an approval threshold?
• Has the receiving event occurred?
• Is the agent authorized to approve, or only to recommend?

Without the ontology, those questions get answered by string matching, prompt heuristics, and luck.

RAG provides evidence, ontology provides meaning

Most teams that have read this far are already running Retrieval-Augmented Generation (RAG). Ontology does not replace it, because the two solve different problems.

RAG retrieves relevant text from policies, knowledge bases, contracts, manuals, and tickets. It is a search problem, and it surfaces the right paragraph.

Retrieval is not understanding. RAG can pull a policy that says "high-risk suppliers require additional approval." It does not know whether this supplier is high-risk. It does not know where the risk status came from. It does not know whether the rule applies in this jurisdiction.

The clean mental model:

RAG provides the reference material. The ontology provides the business model. Constraints, policies, and action schemas turn that model into enforceable operating logic.

In a mature stack, RAG retrieves evidence. The ontology identifies the entities and relationships in that evidence. Reasoning services draw out implications. Policy and validation layers decide what the agent may do. Workflow systems execute. Audit logs preserve the chain.

Skip the ontology and you get a system that retrieves text well and acts on text it does not understand.

Ontology is kinetic infrastructure

Older ontology projects often produced static documentation. They helped humans align on terms, but they did not change operations.

Agents change that. They read records, and they also update them, create tickets, move inventory, approve workflows, generate filings, send messages, and call tools (APIs, CLIs, MCPs, and so on).

Once an AI system can act, business semantics become safety-critical. The ontology stops being a reference artifact and becomes kinetic infrastructure.

A static glossary can define a Shipment. A kinetic ontology connects that Shipment to:

• the Customer Order it fulfills
• the Warehouse responsible for dispatch
• the Carrier responsible for delivery
• the Service-Level Agreement that applies
• the delay rule that triggers escalation
• the inventory records that may change
• the actions an agent may take

This is why agentic platforms organize around business objects, relationships, governed actions, and security. The agent needs more than access to data. It needs access to a governed model of how the business works.

A worked example: approving a supplier payment

Suppose an agent is asked to approve a $250,000 invoice from "Contoso, Ltd."

Without an ontology, the agent retrieves the invoice PDF, finds the supplier name, checks a vendor table, and proposes approval if a row exists.

With an ontology, the agent operates on typed objects:

• The Supplier entity is resolved to the right legal entity in the master vendor system.
• The Invoice is linked to a Purchase Order with a matching amount.
• The Receiving Event is checked against the warehouse log.
• The Approval Policy is evaluated against the amount threshold.
• The Sanctions Status is checked at the legal entity level.
• The agent's Authorization is checked against the action schema.

If any precondition fails, the action is blocked or escalated. If they all pass, the agent acts, and the chain of evidence is logged.

That is the difference between an agent that produces plausible answers and an agent that operates inside a governed model of the business.

In Part 3, I will walk through how to build one of these without a two-year knowledge engineering project, covering workflow selection, source mapping, and ontology ROI.