AI agents are no longer confined to automating processes or answering questions. In finance, they are being asked to release supplier payments and reconcile bank statements; in manufacturing, to work out why a pump on a production line keeps tripping. The large language models behind them read, interpret and draft fluently, but they do not know the business function, dataset or process involved: which purchase order an invoice must match, which sensors are fitted to which pump or who must approve an action.
Those rules and relationships sit in ERP configurations, approval matrices, maintenance records and staff experience, so there is no single, checkable definition of which actions an agent may take on its own. Governance therefore falls back on an all-or-nothing switch: an agent is either locked down, adding little value, or trusted with everything until an incident forces its withdrawal. In my assessment, this is where many agent programmes stall.
An ontology closes that gap: it is a machine-readable definition of a business’s entities, relationships and rules, against which software can check an agent’s answers and actions before they take effect. By grounding what an agent knows and governing what it may do, it lets a business grant autonomy one action at a time, which makes it the backbone of agentic AI. In published tests, representing an enterprise database as a knowledge graph defined by an ontology more than tripled GPT-4’s accuracy on business questions, from 16.7% to 54.2%.
This article explains how an ontology differs from a knowledge graph and a graph database, what the evidence shows, where autonomy should begin and end, and how we apply it at Data Nucleus in finance and manufacturing.
What an ontology is, and what it is not.
More precisely, an ontology defines the classes of entity a business works with (supplier, contract, invoice, purchase order, asset) and the relationships between them (an invoice is issued by a supplier against a purchase order). It also states the constraints the data must satisfy (every invoice has exactly one supplier), which a validation language such as SHACL (Shapes Constraint Language) can enforce, and the rules from which new facts can be inferred.
Its value is easiest to see in an entity that every function touches, such as a supplier. To finance, a supplier is a vendor record; to legal, a counterparty; to procurement, a performance score; to operations, a source of spare parts; and to the executive team, a concentration risk. Each function’s system holds its own version under its own identifier. An ontology treats these versions as one supplier, defines what each view means and links them, so an agent sees the whole supplier rather than a fragment held in one system.
An ontology is often confused with two related terms: a knowledge graph, which is an ontology populated with real instances (this supplier, this contract, this invoice), and a graph database, which is an engine that stores and traverses such a graph.
Graph databases are a natural home for knowledge graphs, because an ontology and its instances together form a network of nodes and links, and questions that span several links can be written as paths through that network rather than as chains of table joins. The three remain separable, however: an ontology can sit over relational tables without a graph database, and many graph databases hold data with no ontology at all.
Does an ontology matter at big-data scale?
An ontology matters more at scale, because the hard problem there is rarely storing data but giving many sources one shared meaning. It does not replace a data lake, warehouse or historian, and it does not need to copy their contents.
Instead, mappings connect its classes to the tables where data already lives. The World Wide Web Consortium (W3C) standardised this approach for relational data in R2RML, which allows a database to be exposed as a knowledge graph, including through virtual endpoints that query it in place (W3C, 2012). High-volume transactions stay in the warehouse and sensor readings in the historian, while the knowledge graph exposes the entities and the links between them, so an agent reasons over business concepts rather than the raw scale of the data estate.
The same mappings also change how data is queried. Rather than interpreting table names and join paths to write SQL, a model writes its query in the ontology’s business terms, such as suppliers, invoices and contracts, and a virtual knowledge graph engine uses the mappings to translate that query into SQL for the source database. The data.world studies covered in the evidence section worked this way, over a virtual knowledge graph mapped to a relational database, which helps explain why accuracy rose there with no change to the model or the data.
An ontology also strengthens the governance work a data platform already does. Master data management produces one golden record for each supplier or asset, and the ontology states what that record means and how it relates to everything else. The same constraints that check an agent’s actions can validate incoming records at ingestion, so inconsistent data is caught before it reaches a report or an agent, and a new source is mapped to existing concepts rather than connected through another point-to-point pipeline.
What an agent gains from an ontology.
A large language model (LLM) brings broad knowledge and reasoning to an agent, and an ontology adds four capabilities that a model cannot provide on its own.
The first is meaning: the same word can refer to different concepts in different departments. To finance, an asset is an entry in the fixed-asset register; to maintenance, it is a pump on a production line. An agent that guesses which one is meant will be confidently wrong in ways that are hard to detect. An ontology removes the guesswork by defining the fixed asset and the physical equipment as two distinct concepts, each with its own definition, and linking them so that an agent knows which one a question refers to.
The second is connection: many of the most important questions cross systems, such as which open invoices belong to a supplier whose required insurance has lapsed, and which of that supplier’s parts are installed on critical equipment. An ontology records how these entities link across systems, so an agent can follow the links from the invoice to its supplier, and from the supplier to its contract and to the parts installed on critical equipment, instead of retrieving passages that merely use similar words.
The third is permission: an operational ontology, extended with a policy vocabulary such as the W3C’s Open Digital Rights Language (ODRL), defines not only the entities an agent works with but also the actions it may take, what must be true before each action runs and who may approve it. Placing a supplier on payment hold, for example, is an action with a precondition, such as an open dispute on the supplier’s account, and an owner, such as the accounts payable manager. Palantir’s Foundry makes this explicit, defining an action type as a set of edits to objects, property values and links that a user can make at once, along with its side effects (Palantir documentation).
The fourth is validation: before an action runs, it is checked against the ontology’s constraints, such as whether an invoice matches an approved purchase order and whether the supplier is still active, and any proposal that fails is stopped before it reaches the ERP or other system of record.
Does an ontology make agents more efficient?
An ontology makes agents more efficient in three ways. First, an agent retrieves less: because the ontology identifies the entities and links a question depends on, the agent pulls a small set of relevant facts instead of many loosely matching passages, which can reduce the tokens, and therefore the cost, of each answer. Second, structured questions become exact lookups: the supplier on a purchase order comes from a graph query, not from a model reasoning over text. Third, fewer answers and actions need rework, because validation catches errors before they reach a report, a person or a system of record. The next section puts numbers on the first and third.
What the evidence shows.
Two studies by data.world tested GPT-4 on business questions over an insurance database built on the Object Management Group’s Property and Casualty data model (Sequeda, Allemang and Jacob, GRADES-NDA 2024; Allemang and Sequeda, ISWC 2024), and the results break down as follows:
Querying the SQL database directly, GPT-4 answered 16.7% of questions correctly.
Querying the same data as a knowledge graph defined by an ontology written in OWL, the W3C’s ontology language, it answered 54.2% correctly.
When deterministic rules derived from the ontology checked each query, and the model had up to three attempts to repair any query that failed, accuracy rose to 72.55%, the error rate fell to 19.44%, and 8% of questions were returned as “unknown”.
The last result is the one I would put in front of any executive. An ontology does not make answers infallible, but it lets a system recognise some of its own errors and decline to answer instead of answering wrongly.
Evidence from production points the same way: LinkedIn’s question-answering system, built on a knowledge graph of historical support tickets, cut median per-issue resolution time by 28.6% after roughly six months in use (Xu et al., SIGIR 2024). Graph structure can also reduce cost: at its most compact setting, Microsoft’s GraphRAG, which builds an entity graph from documents, answered corpus-wide questions with over 97% fewer context tokens than summarising the source text directly, although the graph has to be built and maintained (Edge et al., Microsoft Research, 2024). Even so, the larger efficiency gain is measured in correct answers, visible errors and avoided rework rather than in tokens.
Where autonomy belongs.
Accurate answers raise a practical question: how much autonomy should an agent be granted? An ontology lets an organisation answer that action by action rather than all at once. An agent can act without a person wherever a mistake would be cheap, reversible and caught by validation, as in ingesting and classifying documents, mapping each field to the ontology, recognising the same supplier or asset across systems, checking constraints and recording where each fact came from. Decisions that commit money, change equipment or create a legal obligation go to a person, with the evidence assembled and the reasoning traceable.
This mirrors Anthropic’s guidance on building agents: start with the simplest system that works, accept that autonomy brings higher cost and the potential for compounding errors, and build in checkpoints where an agent pauses for human feedback (Anthropic, 2024). An ontology is where those checkpoints are defined, because each action type carries its own preconditions and approval rule.
Implementation choices for technical teams.
This section is for architects and engineering leads; the business argument does not depend on it. The choices it sets out are the ones that have held up in Data Nucleus products running in production for at least six months.
Graph model. Where formal semantics matter, the W3C stack is the stronger choice: RDF for data, OWL for the ontology, SPARQL for queries and SHACL for validation. Labelled property graph databases such as Neo4j are often simpler for engineering teams to adopt and now have an ISO-standard query language, GQL, which Neo4j’s Cypher largely conforms to. The property graph model has no standard semantics for reasoning, however, so the ontology has to live in application code or a separate schema. Some engines support both graph models; Amazon Neptune, for example, runs SPARQL alongside Gremlin and openCypher.
Reasoning and validation. OWL reasons under an open-world assumption, where a missing fact is unknown rather than false, which suits inference but not authorisation. An agent deciding whether to release a payment needs closed-world checks, which SHACL provides by validating a graph against declared shapes and reporting every violation. The recommended pattern is to let OWL define meaning and SHACL check the data an action would change before anything is committed.
Virtual or materialised. A virtual knowledge graph maps the ontology onto existing databases through R2RML and queries them in place, which avoids duplication and keeps each source system authoritative. A materialised knowledge graph copies entities and relationships into a graph database for faster multi-hop traversal and analytics. The practical answer is to combine both: virtual access for high-volume records, and materialised entities and relationships for the connections agents traverse most.
Provenance. Every fact an agent may act on should carry its source, time, confidence and approval status. PROV-O, the W3C provenance ontology, provides a standard vocabulary for sources, derivations and timestamps, which can be extended to cover confidence and approval status; in a property graph, the same information sits in properties on nodes and relationships.
Hybrid retrieval. Graph traversal answers relational questions, and vector search finds passages in unstructured text. Link each passage to the entities it mentions so that an agent can use structure and detail together; several graph engines, Neo4j among them, now include vector indexes.
Agent interface. Expose the ontology to agents as tools with typed parameters rather than raw query access, and check every query an LLM generates against the ontology before it runs.
When you do not need an ontology.
Not every agent needs an ontology: experience suggests that standard retrieval-augmented generation (RAG) is hard to beat on questions answered from a single passage, while graph-based retrieval is stronger on questions that connect several facts and carries higher construction cost and retrieval latency.
Automatically built graphs have a further limit: when entities are extracted by a model, some of the facts an answer depends on never reach the graph, and no amount of traversal can recover them.
Ontologies also take effort to design and maintain, and they need updating as a business changes. The recommendation is to model the handful of entities and actions your agent’s decisions depend on, and to adopt an established standard where one exists rather than invent your own. For finance, that means FIBO, the EDM Council’s ontology of financial concepts, and for manufacturing, ISA-95 (IEC 62264) for equipment hierarchies and operations.
How we apply it at Data Nucleus.
Two of our platforms, both in production, apply the same pattern in different settings: Nucleus One in finance and Manufacturing Copilot on the factory floor. In each, the ontology defines what the system does alone and what it brings to a person.
Nucleus One reads and classifies financial documents, extracts their data and answers questions on them. Its ontology defines the document types a finance function runs on, including invoices, purchase orders, contracts, bank statements and financial statements, together with their fields and the relationships between them.
Capture, classification, extraction, mapping to the ontology, validation and provenance recording run autonomously, and each extracted value carries a confidence score. Exceptions and approvals go to the finance team, every approval is logged for audit, and approved data flows to the ERP. When someone asks a question, the answer is grounded in their documents alone, with every source cited. We have found that combining knowledge graph and vector retrieval gives more accurate answers on financial documents than either method used on its own.
Manufacturing Copilot answers factory-floor teams’ questions and prescribes fault-rectification actions, drawing on IoT sensor data, manuals, SOPs, wiring diagrams and safety records. Its ontology ties sensor tags from PLC, SCADA and historian systems to the equipment they monitor, links production records from MES to the same equipment, and connects each asset to its documentation and maintenance records. When an engineer asks why a machine keeps tripping, the copilot decides which sources the question needs, retrieves across them, assembles a sourced answer and recommends the next action. The engineer approves that action and carries it out.
What comes next: autonomy granted one action at a time.
The answer to all-or-nothing governance is to grade autonomy for each action rather than for each agent, across four levels: the agent recommends and a person acts; the agent acts once a person approves; the agent acts within set limits and a person reviews afterwards; or the agent acts on its own. Because each action has its own level, with controls that tighten as autonomy rises, a single agent can recommend freely, act on its own for routine and reversible work, and still need approval before it releases a payment.
How does an action move to a higher autonomy level?
Each action type carries its autonomy level alongside its preconditions and approver, so moving it up a level becomes a decision based on evidence rather than faith. That evidence is already in the audit record: how often people amend an agent’s proposals, how often they reject them, how often an action is reversed after the fact, and how often validation catches an error before it takes effect.
An action whose proposals are approved unchanged over a sustained period, within stated value limits, is a candidate to move from acting on approval to acting within limits, and later to acting on its own. Approval rates count only if the reviews were genuine, and because reviews tend to degrade under time pressure or approval fatigue, a sample of approved actions should be checked independently. Equally, an action whose amendment rate rises moves back down.
The autonomous level calls for continuous monitoring, rapid rollback and circuit breakers that halt an agent when thresholds are breached. Those thresholds, such as a value ceiling, a volume limit per hour or a list of counterparties that always require a person, can be modelled in the ontology as properties of each action type, or held in a policy engine that the ontology references. Because these limits are enforced by deterministic checks outside the model, rather than written into its prompt, an agent cannot reason its way around them.
What changes when agents work together?
The larger shift is that agents will increasingly hand work to one another, and a shared ontology gives them a common vocabulary, so each understands what the other means. When a maintenance agent orders a replacement part, the purchase order it raises is the same object a finance agent later matches against the supplier’s invoice, and the supplier is the same entity the legal team holds a contract with.
Without a shared ontology, every hand-off between agents becomes a translation problem; with one, the whole chain shares the same definitions and permissions, and a single audit trail. This is where finance and operations stop being separate AI projects and become one governed system.
The organisations that go furthest with agentic AI will not be those with access to the most capable models, since that access is widely shared. They will be the ones that wrote down how their business works and what their agents may do, and then let the evidence decide how far to trust them.
Which action in your organisation would you trust an agent to take on its own first, and what evidence would you want to see before you did? If you are working through that question now, I’d welcome the opportunity to compare notes.
Disclaimer: This article is for information only and may change without notice. It is provided “as is,” without warranties (including merchantability or fitness for a particular purpose), and does not create any contractual obligations. Data Nucleus Ltd is not liable for any direct, indirect, incidental, special, consequential, or exemplary damages arising from use of or reliance on this document.
Data protection/UK GDPR: data-controller@datanucleus.co.uk