The ontology as the agent's context
Quick answer:
Giving an agent access to the database is not giving it context. It is giving it a language it does not speak and asking it to guess the rest.
When an agent fails at a business task, the usual diagnosis is "the model isn't good enough". It almost never is. The model does not know what a customer means in this company, what separates an order from a delivery note, or who may approve a return. And none of that lives in a table.
The bottleneck is not the model
A database schema describes how information is stored: tables, columns, keys. It does not describe what it means. cust_id_2 might be the customer who is invoiced or the one who receives; the schema does not say, and the agent does not guess.
The usual escape is to put that explanation in the prompt. It works with five tables. With two hundred, the context does not fit, changes weekly and nobody owns it. That is technical debt dressed as text.
What an ontology adds
An ontology describes the business in the business's own terms. It has three things a schema does not:
Objects with names of their own
Customer, order, installation, policy, work order. Not tables: concepts, with their properties and an agreed definition. When two departments disagree on what an active customer is, the ontology is where the argument gets settled and written down.
Explicit relations
An order belongs to a customer, contains lines, ships from a warehouse and generates an invoice. Those relations are declared, not inferred from similar-looking column names. The agent can traverse them without inventing them.
Actions with permissions
Here is the difference that matters for an acting agent. The ontology does not only say what an order is: it says what can be done to it — cancel, reschedule, apply a discount — under which rules and with whose permission. Without that layer, every action is hand-built and permissions end up living in the code of each integration.
This is exactly what we describe when discussing Palantir's Ontology from a data governance angle: the value is not in a pretty graph, it is in actions carrying their rules attached.
Table versus object: an example
Without an ontology, an agent answering "can we ship this order this week?" needs to know which tables to join, which statuses mean "confirmed", which warehouse applies and which column holds the delivery commitment. All of that has to be written out for it.
With an ontology, the agent traverses order → lines → availability → warehouse, because those relations exist as such, and consults the commitment rule where it is defined. Reasoning stops being guesswork and becomes traversal.
How to build one, and how not to
How not to: modelling the entire company before delivering anything. That is the eighteen-month project that dies in month twelve with a beautiful dictionary no system uses.
How to, in four steps:
- Start from a use case with an owner. A concrete question somebody needs answered or a concrete action somebody needs executed.
- Model only the objects that case touches. Usually between four and eight.
- Declare actions and their permissions alongside the objects, not afterwards.
- Extend when the next case arrives, reusing what is modelled.
In our experience with MVP60™, the minimum ontology for a first use case takes weeks rather than quarters, precisely because it is scoped to what the case needs.
Common mistakes
- Copying the schema and renaming it. If the objects are named after the tables, nothing has been modelled.
- Modelling without actions. What remains is a dictionary, not an operational layer.
- Leaving it outside governance. An ontology without an owner goes stale and returns to the prompt.
- Confusing it with a catalogue. The catalogue says where the data is; the ontology says what it means and what may be done with it.
How Galde can help
We design ontologies scoped to real use cases, with their actions and permissions, on the Palantir Foundry Ontology. The standard is the same as always: the internal team maintains the model once we leave.
Conclusion
Vendors are converging on the diagnosis: what holds agents back is business context, not model capability. The practical conclusion is less glamorous than a new model, but more profitable: before asking an agent to act, you have to teach it what the company is made of.
And that is taught once, in one place, with an owner. Not in every prompt.
Frequently asked questions
What is an ontology in the context of enterprise AI?
It is a representation of the business in its own terms: objects such as customer or order, the relations between them and the actions that can be executed, with their rules and permissions. Unlike a database schema, it describes meaning rather than storage.
Isn't giving the agent database access enough?
No. The schema says how information is stored, not what it means or what can be done with it. Without that layer, context ends up written in the prompt, where it neither scales nor gets maintained.
How long does a useful ontology take to build?
Scoped to a concrete use case, weeks. The project that takes quarters is the one trying to model the whole organisation before delivering value, and it usually never reaches production.
Does an ontology replace the data catalogue?
No, they complement each other. The catalogue answers where the data is and where it came from; the ontology answers what it means and which actions it supports.
