Ontology vs Knowledge Graph: Which Your AI Workflows Need

A knowledge graph is your data connected as entities and links. An ontology is the layer of definitions and rules that says what a customer, an order or an approval means and what must hold between them. If an AI agent only needs to look things up, a graph is often enough. If it has to act, you need the ontology on top.

The terms get used as if they were rivals. They aren't. The graph holds the facts and the ontology governs them. This post uses one example, a single customer sitting in a CRM, an ERP and a spreadsheet, to show where a plain graph stops being enough, and how Helix Foundry builds and maintains the rules layer so you don't hand-write it.

Ontology vs knowledge graph in one paragraph

A knowledge graph stores nodes (a customer, an order) and edges (placed, approved, billed to). An ontology defines the types those nodes can be, the links allowed between them, and the rules that must hold, such as "an order above a threshold needs an approval before it ships." The graph is the connected data. The ontology is the meaning and the constraints. Foundry's own description of an ontology matches this: it holds the types, links and rules that describe your data, along with its versions and loads.

Three questions come up constantly, so here are direct answers.

What is ontology in simple terms?

An ontology is a shared, written-down agreement about what things exist in your business, how they relate, and what rules apply. It answers "what do we mean by a customer, and what has to be true about one?"

What is the difference between an ontology and a taxonomy?

A taxonomy is a hierarchy of categories, like a product tree with parent and child groups. An ontology allows many kinds of relationship, not only "is a kind of," and it carries rules. A taxonomy tells you a Premium plan is a type of Plan. An ontology also says a Premium customer must have a billing contact and an active contract.

What is the difference between an ontology and a schema?

A schema describes how data is stored in one system: tables, columns, types. An ontology describes what the data means across systems and what must hold between entities. Your CRM has a schema and your ERP has a different one. The ontology is the model that says both rows are the same customer and what rules apply to it.

One customer in a CRM, an ERP and a spreadsheet

Take Acme Logistics. In the CRM it is "Acme Logistics Ltd" with an account owner and an open opportunity. In the ERP it is customer ID 40217, "ACME LOGISTICS LIMITED," with invoices and a credit limit. In a finance spreadsheet someone keeps, it is "Acme Log." with a note that says "approved to go over limit, per Sam."

That's one customer in three places, under three names, with three different slices of the truth. Load all three into a graph and you get nodes and edges. You don't automatically get the knowledge that these are one company, or that the spreadsheet note is an approval that overrides a credit rule.

Ask an agent "can we ship Acme's new order?" and the answer depends on all three: the open deal in the CRM, the credit limit and unpaid invoices in the ERP, and the informal approval in the sheet. A plain graph can store each fact. It can't tell the agent which facts count or what must be true before it acts.

When a plain knowledge graph is enough

A plain graph is enough when the job is retrieval and the entities are already clean. If your data has one system of record for each entity, consistent IDs, and the agent only answers questions ("which accounts did this rep touch last quarter?"), connecting the data into a graph gets you most of the value. Traversal follows the links and returns context a vector search alone would miss.

It's also enough for exploration. Analysts who want to see how customers, orders and tickets relate, and who will judge the result themselves, don't need enforced rules. A human is the rules layer.

If that describes your workflow, build the graph and stop. An ontology you don't need is overhead. For a longer checklist, see Do You Need an Ontology? Five Signs Your Data Needs One.

When you need the rules layer: three tests

You need the ontology when any of these three tests fails.

Test 1: Is the same entity under different names in several systems? Acme Logistics Ltd, ACME LOGISTICS LIMITED and Acme Log. must resolve to one customer, or every count, total and answer is wrong. This is entity resolution, and it needs a definition of what makes two records the same.

Test 2: Are there business rules an agent must not break? "No shipment over the credit limit without approval" isn't a fact. It's a constraint. If an agent acts on your data, those rules have to be checked where the data lives, not remembered in someone's head or a prompt.

Test 3: Must answers trace back to a source? When an agent tells finance a customer is over limit, someone will ask where that came from. You need each value tied to the row or document quote behind it, not a number the model produced.

Fail one and a graph alone will give you confident wrong answers. Fail two or three and an agent acting on that graph is a risk. Industry versions of this problem show up in insurance, logistics and finance ops.

How to build the ontology on top of the graph, with any tool

The steps are the same whatever tool you use.

1. List the entities that matter. Customer, order, invoice, approval. Keep it to the nouns your workflow actually touches.

2. Define the links. An order is placed by a customer, an invoice bills a customer, an approval covers an order. Say which links are allowed.

3. Write the matching rule. Decide what makes two records the same customer: a tax ID, a normalised legal name plus country, an email domain. Be explicit about what is a match and what goes to a person.

4. Write the constraints. Express each business rule as something checkable, such as "an order over the limit has a linked approval."

5. Map each source to the model. Say which CRM field, ERP column and spreadsheet cell fills which property.

6. Keep evidence. Store where each value came from so any answer can be traced.

Done by hand, this is real work and it rots. Every new source or renamed column means revisiting all six steps. That upkeep is the hard part, and the next section automates it. For a fuller walkthrough, see How to Build an Ontology From Scattered Company Data.

Doing it in Helix Foundry: self-hosted or Helix Cloud

Helix Foundry turns the tools your company runs on into one connected graph. You connect your databases, tools and documents, and Foundry's agent drafts an ontology over them: types, links, mappings from your tables, routes for your documents, rules, and the questions it should answer. The ontology loads into HelixDB, the graph-vector database Foundry runs on, so it's one connected graph you can explore and ask questions of, with each value traced to its source.

For the Acme example, you'd connect the CRM, the ERP's database and the spreadsheet's export, then generate. The draft links the three customer records as one customer and proposes the credit-limit rule as a constraint. You review the draft, edit it, and make it current. Versions never change once drafted, so you can always see what the model said at any point.

To run it yourself, Foundry is open source under Apache 2.0:

git clone https://github.com/helixdb/helix-foundry.git
cd helix-foundry
docker compose up -d --wait

Then open http://localhost:3000. You need Docker with Compose v2 and ports 3000 and 8333 free. The local install is for one person on their own computer, so don't expose it to a network. To skip the setup, use Helix Cloud at foundry.helix-db.com and choose Set up with your agent. Creating an ontology, including its database, is covered in the create an ontology guide.

Keeping it correct as data and schema change

An ontology that was right in March is wrong by September unless something maintains it. Sources add columns, teams rename fields, a new system arrives, and the matching rule that worked for 500 customers misses edge cases at 5,000.

Foundry handles the parts that usually break. It drafts correct links between entities across sources and flags records that don't add up for a person to review, instead of writing uncertain values silently. It also drafts new versions as your data and workload change rather than editing the live one in place. You generate a new version, review it against the current one, and make it current when you're happy. Nothing is written until you confirm.

That review step matters. Rules and uncertain matches go to a human, and every value stays traceable to the row or document it came from. Foundry also never writes back to your sources, so a bad draft can't damage the CRM or ERP.

Trade-offs and what Foundry does not do

Be honest about the cost. An ontology is more to maintain than a graph, and for clean single-system data it's more than you need. If the three tests above all pass, skip it.

Foundry never writes to your sources. It reads and models them. If you want an agent to change the ERP, that action sits outside Foundry. Generating a draft sends your synced tables and sample documents to Foundry's agent, so know what you're connecting before you sync it. The self-hosted install is single-user and local by design.

And a drafted ontology is a draft. A person approves the rules. The agent does the heavy lifting, but you own what "customer" means.

FAQ

See the questions below for quick answers on the most common points of confusion.

Start with one customer and the rules that matter

Use a plain knowledge graph when your agent only reads clean, single-source data. Add an ontology the moment the same customer shows up under three names, or an agent has to obey a rule or show its sources. The fastest way to know which you're in is to try it on one real entity. Clone helix-foundry, connect two systems that both hold your customers, generate a draft, and see whether it links them correctly and flags what doesn't add up.