Your AI Agent Found the Right Document. Can It Safely Act?

Imagine an AI supply-risk agent detects that a critical component may arrive after a factory is scheduled to run out.

The system retrieves the supplier's delay notice, open purchase orders, an inventory snapshot, the approved-source list, the contract, and the production plan. The model reads the evidence and recommends an expedited order from an alternative supplier.

That looks like a successful RAG system. It found the right documents. The answer may even cite them accurately.

The recommendation could still use the wrong part revision, count inventory that is under quality hold, overlook an inbound shipment, choose a substitute approved for another facility, duplicate an open order, exceed the agent's spending authority, or update one system while leaving another unchanged.

Another paragraph of context will not resolve those risks. The system needs an explicit account of the component and revision, the facility that consumes it, usable inventory, open supply, approved substitutes, contract commitments, production demand, and the authority required to create or expedite a purchase.

This is where the conversation about AI agents becomes much more interesting. RAG improves what a model can see. An agent that acts in the world also needs shared meaning, connected state, enforceable constraints, and clear authority.

Ontologies and knowledge graphs can provide part of that foundation. They are powerful precisely because they solve a different problem from retrieval. They also come with an important limitation: meaning alone does not make an action safe.

A language model can produce fluent answers from patterns learned during training, but its internal knowledge may be incomplete, stale, or disconnected from an organization's private information.

Retrieval-augmented generation gives the model an external memory. When a user asks a question, the system searches a collection, selects relevant material, and places that material in the model's context before it answers. The original RAG paper described this as combining a model's parametric memory with retrieved non-parametric memory. In its experiments, RAG produced more factual language than the parametric-only baseline.

That was an important advance. A well-built RAG system can:

• answer from private or recently updated documents;
• show the evidence used for an answer;
• reduce reliance on whatever the model happened to learn during training;
• narrow a large information collection to a useful working set.

The hard engineering work is familiar by now: clean the source material, split it sensibly, preserve metadata, improve queries, combine semantic and keyword retrieval, rerank results, manage context, and evaluate the complete pipeline.

None of this is trivial. None of it should be dismissed.

The problem begins when we expect retrieval to do jobs it was never designed to do.

Retrieval can surface a contract or procedure that appears relevant. It does not guarantee that the document is current, that it applies to this component revision and facility, that two records refer to the same physical item, or that the requested purchase is permissible. Vector similarity is a relevance signal, not a truth test or an authorization decision.

Even the presence of a correct passage does not force a generative model to use it correctly. NIST's Generative AI Profile treats confident false output as an enduring risk. Its related controls include reassessing model risk after RAG is implemented, grounding retrieval data, reviewing sources and citations, and documenting human-oversight roles.

RAG can make the system better informed. Reliability still depends on the architecture around the model.

A question-answering assistant can be wrong in ways that are frustrating. An agent can be wrong in ways that change inventory, send money, expose data, cancel an order, create a purchase request, or alter a production system.

Agency changes the standard because the model is no longer producing text for a person to consider. It is proposing or executing a state change.

That introduces a set of questions a document search cannot answer on its own:

• Identity: Do the internal part number, supplier code, and engineering revision refer to the same approved component?
• Meaning: Does “available inventory” exclude stock under quality hold, reserved for another order, or located at a different facility?
• Relationship: Which supplier, contract, purchase order, shipment, facility, and production schedule belong to this requirement?
• State: Has an order already been created, acknowledged, shipped, received, cancelled, or replaced?
• Constraint: Is this combination of facts valid?
• Authority: May this agent perform this action, for this amount, in this jurisdiction, at this time?
• Execution: Can the transaction be retried without creating a second order, observed after release, and reversed if something fails?

Those questions live across data, semantics, policy, security, and operations. Treating all of them as a search problem makes the agent look smarter while leaving the system underneath it ambiguous. I find that ambiguity easier to manage when the architecture separates six layers.

• RAG. Relevant passages and evidence It answers: “What information might help with this request?” It does not guarantee: That the evidence is complete, correctly interpreted, or sufficient for action.
• Ontology. A shared vocabulary and explicit relationships among concepts It answers: “What do these terms mean in this domain?” It does not guarantee: That every fact is present or every proposed action is allowed.
• Knowledge graph. Specific entities, facts, and links represented in that domain model It answers: “What is connected to this component, facility, supplier, contract, and event?” It does not guarantee: That the data is correct, current, or policy-compliant.
• Reasoning and validation. Inferred facts plus checks against explicit conditions It answers: “What follows from these facts, and does this proposal conform?” It does not guarantee: That the caller has permission or the transaction will execute safely.
• Authorization and transaction controls. Identity, scope, approval limits, idempotency, and safe state change It answers: “May this actor do this, and can the system do it safely?” It does not guarantee: That the business decision is wise or the underlying policy is fair.
• Human and operational governance. Ownership, escalation, monitoring, audit, correction, and rollback It answers: “Who accepts the consequence and what happens when the system is wrong?” It does not guarantee: Perfection; it creates accountability and recovery capacity.

Each layer fails differently. A retrieval failure may omit the governing contract. A modeling failure may confuse two revisions of the same component. A graph-quality failure may link inventory at the wrong facility. A validation failure may accept an unapproved substitute. An authorization failure may let the agent exceed its spend limit. An operational failure may create a purchase order but fail to record the result, allowing the next retry to create another.

Calling all of this “reasoning” hides the places where responsibility actually sits.

An ontology is a formal account of a domain's vocabulary. It defines concepts, properties, and relationships so people and machines have a shared interpretation. The W3C's OWL overview describes ontologies as formalized vocabularies whose terms are defined through their relationships with other terms.

In an industrial supply domain, an ontology might define:

• a Component as distinct from a specific ComponentRevision;
• revisionOf as a relationship from a revision to its component family;
• consumedAt as a relationship from a component revision to a facility;
• approvedFor as a relationship connecting a supplier source to a revision and facility;
• fulfills as a relationship from a shipment to a purchase order;
• a PurchaseRequest as a proposal that is distinct from an approved PurchaseOrder.

That vocabulary gives the system a stable semantic backbone. A component stops being whichever document happened to contain a similar part description. It has an identity, revision, known relationships, and a definition that engineering, procurement, inventory, logistics, and production systems can map to.

A knowledge graph records the specific facts:

• Revision B belongs to Component C-184.
• Facility North consumes Revision B.
• Supplier S-27 is approved to supply Revision B to Facility North.
• Purchase Order 611 contains 600 units of Revision B and is awaiting shipment.
• Inventory Lot L-92 contains 400 units and is under quality hold.
• Production Requirement R-4 needs 900 usable units before the next scheduled run.

Now the agent can retrieve documents and traverse connected facts. It can ask which contract applies to Supplier S-27, whether the open order covers the production requirement, or which inventory lots are actually usable. A reasoner may also derive facts that were not written explicitly. If every quality-held lot is classified as non-usable inventory and Lot L-92 is quality-held, the system can infer that those 400 units should not satisfy the usable-inventory requirement.

This is a different kind of capability from “find me similar text.” It gives the organization a machine-readable model of the domain.

The model is still only as trustworthy as its definitions, mappings, data sources, and governance. A knowledge graph built from incorrect extraction can make an error easier to traverse. A beautifully designed ontology can formalize the wrong business assumption. Structured data makes ambiguity visible; it does not make human judgment unnecessary.

Return to the delayed component. A reliable decision flow might work like this.

The system connects the internal component, engineering revision, supplier code, facility, inventory lots, open purchase orders, inbound shipments, and production requirement. Authoritative IDs and controlled mappings matter more than a description that happens to sound similar.

If the component revision or facility cannot be resolved with sufficient confidence, the system stops. Guessing the entity would contaminate every later step.

RAG gathers the governing contract, supplier notice, approved-source record, quality status, logistics quote, and production plan. Each passage keeps its source, version, effective date, and access context.

The agent now has material it can cite. It has not yet earned the right to act.

The ontology tells the system how ComponentRevision, Facility, InventoryLot, PurchaseOrder, Shipment, ApprovedSource, and ProductionRequirement relate. The knowledge graph supplies the instances involved in this case.

This is where the model can distinguish “stock recorded in the warehouse” from “inventory available for this production requirement.” A quality-held lot, stock reserved for another order, or units at the wrong facility may all appear on hand. None necessarily solves the shortage.

The system may infer that a supplier is eligible for this requirement because of the approved source, component revision, facility, contract, and effective date. It then validates the proposed data and action:

• exactly one authoritative component revision and facility are attached;
• any substitute is approved for that revision and facility;
• inventory calculations exclude holds, reservations, and unrelated locations;
• source timestamps meet the decision's freshness threshold;
• required evidence is present;
• no open purchase order or inbound transfer already covers the shortage;
• the expedited quantity follows from the remaining net requirement.

Some of these checks fit a graph-validation language such as SHACL. Others belong in deterministic application code or a policy engine, especially when they involve time-sensitive inventory, demand calculations, contract limits, or cross-system state.

A semantically valid expedite can still be unauthorized. The agent's identity and tool permissions must limit the supplier, facility, quantity, spend, and contract terms it can touch. A small premium within an existing agreement may be pre-approved; a large order, a new supplier, or a contract change may require human review.

The ontology helps the system understand the case. Authorization decides whether this actor may change it.

The transaction uses a verified idempotency mechanism with a scoped request key, concurrency control, and checks against the purchasing system's returned result to reduce duplicate order creation across retries. The system records the evidence, proposed action, validation result, approver, tool call, and purchasing-system receipt. Reconciliation still matters: if the ERP creates the purchase order but the agent workflow fails to record the result, the next run must detect that ambiguous state rather than assume nothing happened.

This last step is easy to overlook because it is less impressive than a model demonstration. It is also where an agent becomes part of a real operating system.

This is the technical distinction I would want every team evaluating ontologies to understand.

An ontology language such as OWL is primarily descriptive. It expresses what concepts mean and which conclusions follow from stated facts. It operates under an open-world assumption: missing information may simply be unknown, rather than false.

That differs from the closed-world behaviour people expect from a database form or API validator.

Suppose an ontology says a purchase proposal can have at most one destination facility. If the graph contains two facility identifiers, an OWL reasoner does not automatically behave like a form that flashes “duplicate value.” Depending on the rest of the model, it may conclude that the identifiers refer to the same facility, or it may find the assertions inconsistent if their distinctness is established.

Likewise, a domain or range declaration does not necessarily reject an input with the “wrong type.” If suppliedBy has the range Supplier and a record points to an entity currently labelled as a carrier, a reasoner may infer that the entity is also a supplier unless the model establishes an incompatibility. The OWL 2 Primer warns that domain and range statements can cause new class membership to be inferred; they are not database-style input constraints.

When the requirement is operational—one resolved facility, an approved source, current inventory data, and a quantity within a permitted range—the system needs explicit validation. SHACL was designed to validate RDF graphs against conditions such as datatypes, allowed values, and cardinalities. Application code may enforce the transactional rules that depend on current inventory or side effects.

A clean architecture gives each layer one job. The ontology defines meaning, the knowledge graph connects facts, reasoning derives implications, and validation rejects malformed or non-conforming proposals. Authorization limits power, transactional software changes state safely, and human governance owns exceptions and consequences.

Ontologies become much more valuable when we stop asking them to perform every other layer's job.

GraphRAG is an important development, but the word “graph” is doing too much work in many architecture discussions.

Microsoft Research's GraphRAG approach uses a language model to derive an entity graph from source documents, group related entities, and create community summaries. The researchers reported improvements over conventional RAG for a class of global sensemaking questions, such as identifying themes across a large corpus.

That solves a real retrieval problem. Conventional RAG often performs best when the answer sits in a small number of locally relevant passages. Questions about patterns across the whole collection require a wider view. A graph index can make those connections easier to retrieve and summarize.

An extracted retrieval graph is not automatically a governed business ontology. It may not define formal semantics, distinguish authoritative from inferred facts, enforce constraints, preserve current operational state, or determine who may act. Its nodes and edges can also inherit extraction errors from the model that created them.

GraphRAG and ontology-backed systems can work together. One helps the agent discover relevant patterns and evidence. The other can give the organization a curated language for the domain and connect evidence to authoritative entities. The right design depends on the question being answered and the consequence of being wrong.

Ontologies and knowledge graphs carry a real maintenance cost. Concepts change. Source systems disagree. Mappings drift. Experts need to resolve definitions. A semantic layer without ownership becomes another stale database with more ambitious terminology.

The investment becomes attractive when several of these conditions are present:

• the same entity appears under different identifiers across multiple systems, and teams do not share a stable vocabulary for it;
• decisions depend on relationships that span documents, databases, events, and organizational boundaries;
• the agent must explain which facts and rules led to a proposal;
• multiple applications need a shared domain model;
• the cost of a wrong action is materially higher than the cost of a wrong answer;
• the domain is stable enough to model, important enough to govern, and has a named owner for definitions, source authority, and changes.

A conventional RAG system may be sufficient when the use case is low-risk document assistance, the corpus is small, the answer will always be reviewed by a person, and the important facts already live in one well-designed system.

Sometimes a relational database, typed API, and deterministic policy service are the simplest correct solution. “Knowledge graph” should never become a prestige layer added to architecture without a specific decision it improves.

The fastest way to make ontology work fail is to begin with “model the whole company.” The useful starting point is one consequential decision with clear boundaries.

For example: Should this delayed component be expedited automatically?

Then work outward.

1. Write the questions the system must answer. Which component revision and facility are involved? What inventory is truly usable? Which supply is already committed? Is the substitute approved? What evidence is required? When must a person approve?
2. Name the authoritative sources. Decide which systems own component identity, engineering approval, inventory status, production demand, supplier commitments, contracts, and purchase-order state. Preserve provenance for every mapped fact.
3. Define the minimum shared vocabulary. Model only the entities and relationships needed for the decision. Reuse established standards where they genuinely fit, but do not import a giant vocabulary merely because it exists.
4. Separate fact, inference, and policy. Record what came from a source system, what a reasoner derived, and which rule accepted or rejected the proposal.
5. Build golden cases before autonomy. Include normal approvals, ambiguous identities, missing evidence, conflicting policies, duplicate events, stale data, partial failures, and adversarial requests.
6. Run read-only first. Let the agent propose a decision and explanation while the existing process remains authoritative. Compare outcomes, study disagreements, and improve the model.
7. Add narrow permissions and safe transactions. Give the agent the smallest capability required, set value thresholds, design side effects for safe retries, verify provider outcomes, and preserve a human escalation path.
8. Version the meaning. Ontologies, mappings, rules, and policies need change review, owners, effective dates, tests, and rollback just like software.

The result may begin as a small semantic model around one workflow. That is enough. A useful ontology earns the right to grow by making a real decision clearer, safer, or easier to audit.

RAG made it possible to bring better evidence into a model's working context. Ontologies and knowledge graphs can make the surrounding domain more legible to machines. Validation, permissions, and transaction controls can turn that understanding into bounded action.

None of these layers removes the need for judgment. They make the judgment visible.

For me, that is the more important ambition for agentic AI. I do not want an agent that merely sounds as though it understands the business. I want a system that can show which entity it resolved, which evidence it used, what each term meant, which rule it applied, why the action was permitted, what state changed, and who can correct it.

That standard applies far beyond this supply example. It matters anywhere an agent touches a customer account, financial process, production system, supply chain, or public service.

The next generation of useful AI will need more than larger context windows and cleverer retrieval. It will need organizations to make their own meaning, rules, and responsibilities explicit.

And that may be the most eye-opening part of the ontology conversation: the hardest knowledge to encode is often the knowledge a company assumed everyone already shared.

For the human ownership side of this argument, read AI Can Write the Code. You Still Own the System.

• Lewis et al., “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks”, 2020.
• National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, 2024.
• W3C, OWL 2 Web Ontology Language: Document Overview, 2012.
• W3C, OWL 2 Web Ontology Language: Primer, 2012.
• W3C, Shapes Constraint Language (SHACL), 2017.
• Edge et al., “From Local to Global: A Graph RAG Approach to Query-Focused Summarization”, 2024.