Ontology in AI: giving an agent a map of how your business fits together

In AI, an ontology is a formal description of the things a business deals with (customers, loans, orders, machines): what each one means, and how they relate under the business's rules. An AI agent uses it to ground its answers. Before it writes a query, it checks what the words in the question refer to and which relationships are allowed. A data ontology is the same idea tied to the real tables and columns where those things are stored.

Language models know a great deal about language and almost nothing about your business. They don't know that "customer" means one thing in your CRM and another in billing, or that a repayment can't be dated before the loan it repays. An ontology is where that knowledge goes, in a form both people and software can read.

An ontology describes meaning, and a database stores values

Take a lender. Its loan system has tables called things like ln_acct, cust_mst, rpmt_txn and coll_dtl. An ontology for the same business says something closer to how people talk:

• A Loan is held by exactly one Borrower and may have several Repayments.
• A Repayment belongs to one Loan, and its date can't be earlier than the loan's disbursement date.
• An Overdue Loan is a Loan with a repayment more than 30 days late.
• A Co-lending Loan is a Loan funded by two lenders, each holding a share.

Written in OWL, the web standard for ontologies, the first of those lines looks like this:

:Loan       a owl:Class .
:Borrower   a owl:Class .
:Repayment  a owl:Class .

:hasBorrower a owl:ObjectProperty , owl:FunctionalProperty ;
    rdfs:domain :Loan ;
    rdfs:range  :Borrower .

:repays a owl:ObjectProperty ;
    rdfs:domain :Repayment ;
    rdfs:range  :Loan .

The ontology on its own holds no rows. It becomes useful to an AI agent when it's mapped to the data: :Loan is the ln_acct table, one row per loan, and :hasBorrower is the join from ln_acct.cust_no to cust_mst.cust_no. Then a question about "overdue co-lending loans" can be turned into SQL against the real tables, using definitions the business agreed on.

Why AI needs an ontology

An agent that writes SQL against a raw schema is guessing from column names. Adding an ontology gives it two kinds of grounding.

Grounding in meaning. When someone asks about "active borrowers", the agent looks up what "active" means here instead of inventing a plausible rule. When two tables both have a cust_no, the ontology says whether they refer to the same Borrower.

Grounding in rules. The ontology says what must be true, so the agent can test its own answer. A repayment dated before disbursement, or a percentage of time above 100%, tells the agent its query is wrong before a person ever sees the number.

OWL has profiles built for exactly these jobs. OWL 2 RL suits rule-based reasoning: deriving new facts from the ones you have, such as "this borrower is a related party because both firms share a director". OWL 2 QL suits answering questions over relational data: a question asked in business terms is rewritten into SQL against the tables where the data already lives, so nothing has to be copied into a new store first.

Hand-built ontologies, and ones that build themselves

For most of its history, ontology engineering has been specialist work. Someone interviews the business, models classes and relationships, maps them to data, and maintains the result as the business changes. It produces excellent ontologies and takes a long time.

That's changing. Palantir customers model object types and links in Foundry. Stardog's Voicebox now proposes ontologies and source mappings with AI, for people to review and publish. Databricks describes Genie Ontology as a knowledge graph built from governed tables, queries and dashboards.

The question worth asking any of them is where the first draft comes from, and who checks it.

How to build an ontology from your databases

1. Start from the questions people ask. Model the entities and relationships that show up in real questions first.
2. Draft entities from the schema and the data. Tables and columns suggest candidates; profiling the data shows which ones are real, which are empty and which are duplicates.
3. Map relationships, keeping declared and inferred apart. Foreign keys in the schema are facts. Joins inferred from matching values are proposals, with evidence.
4. Seed definitions from SQL people already trust. A report query that finance has relied on for years is the best available definition of the number it produces.
5. Write the rules down. The constraints a correct answer must satisfy belong in the ontology, where an agent can check them.
6. Have the business review it, then keep it growing. Someone who knows the area approves each meaning. New tables and new findings extend the ontology from there.

How Antcluster builds an ontology for AI from your data

Antcluster connects read-only to your relational databases and does the drafting in steps 2 to 5, then puts the result in front of your engineers. Here is what a team can do with it.

Ask what the business already knows

People can ask questions in plain language across the connected data and get answers with the SQL and records behind them. Within the workflows Antcluster supports, nobody hand-builds a semantic layer first or writes SQL for each question.

Make unwritten knowledge usable

Much of what a business knows about its own data was never written into a database: that two customer tables refer to the same people, that a status code changed meaning after a system upgrade. Antcluster proposes these relationships from the data and from trusted SQL, shows the evidence and confidence for each, and keeps them separate from relationships declared in the schema. Your experts confirm or reject them. Some will be things your team already knew, now available to every investigation. Others will need an expert's judgment before anyone relies on them.

Discover relationships nobody has recognised yet

With the business connected in one ontology, people can apply what they know to relationships no one had looked at. Picture a lender where the credit team understands exposure, the collections team understands repayment behaviour and the operations team sees processing exceptions. Each team's knowledge sits in its own systems and its own heads. A shared ontology lets someone ask whether these signals connect: whether borrowers with a certain pattern of processing exceptions later fall behind on repayments, say, in a way none of the three teams would have spotted alone. Antcluster returns findings like that as testable hypotheses with their evidence. Treat them as starting points for an investigation, since they don't prove cause.

Why this is possible now

A few years ago, few small software teams would have tried to port a whole console game to PC or write their own GPU shaders on a short deadline. With agent harnesses like Claude Code, teams now try work of that size. A harness is the working environment around the model, meaning the tools and context it can use plus the feedback that tells it when it's wrong. Software is a good place for one. Code has interfaces, types in many languages, and tests and builds that connect what an engineer meant to something an agent can verify.

Most company data has no equivalent. A database knows that a value is a date or a number. It doesn't know what the value means for the business or how it relates to data held by another team, and that knowledge sits with people. An ontology is that missing shared understanding, written down so an agent can check against it. With it, data work can reach escape velocity: teams spend less time rebuilding context for each investigation and have more capacity to follow a new question where it leads. That applies to the data team and to the people in credit, operations or finance who've never written SQL, in a ten-person company and in a large bank alike, and it widens what they can attempt: new use cases, and risks or problems no one had thought to look for.

The ontology grows with the business

Antcluster treats the database, the agent harness and the ontology as one connected system that develops through use. The ontology and the graph of your data shape each investigation, and what the investigation confirms flows back, such as an expert's correction or a query worth reusing. The ontology is written in OWL 2, using the RL and QL profiles, and it expands itself as approved findings and new tables arrive. Every change stays reviewable, and a proposed relationship is marked as proposed until someone validates it. Nothing is ever written to your source databases.

Two practical results follow. A question your team has settled is answered with the same logic every time, and a corrected mistake stays corrected. A new question comes back with its assumptions listed, so people can tell an exploration from an agreed answer.

How fast you get started

Understanding a 2,000-table database typically takes two to four analysts and engineers three to six months. Antcluster gets to the semantics of a database that size in a single day, for your engineers to review.

Questions about ontology in AI

What is an AI ontology? An ontology an AI system uses to understand a domain: the entities, what they mean, how they relate and which rules hold. For AI agents working on company data, it's what lets them turn a business question into the right query.

What is a data ontology? An ontology mapped to the data that represents it. Each class and relationship points at the tables, columns and joins where it's stored.

Is an ontology the same as a taxonomy? No. A taxonomy is a hierarchy of categories, such as product types. An ontology adds relationships between different kinds of things and the rules that hold between them.

Do large language models need an ontology if they've read everything? They've read about loans in general. They haven't read about yours. An ontology supplies the definitions and relationships specific to your business, which no amount of training data contains.

What is OWL? The Web Ontology Language, a W3C standard for writing ontologies. OWL 2 RL and OWL 2 QL are two of its profiles, designed for rule-based reasoning and for querying relational data respectively.