Ontology: Teaching AI Agents How Your Company Works

Turkish version: 🇹🇷 Türkçe.

LLMs may know a great deal about the world. But they do not automatically know your company’s domains, the concepts within them, or their domain rules. That means your AI agents do not automatically know how your company works either.

An agent can access your company’s tables, documents, and APIs and still misunderstand what a verified customer is. Because access is not understanding.

Ontology may look like a conceptual topic at first. Yet implementing it in a company that works with AI agents requires thinking across domain modeling, data and integration architecture, security and authorization, business rules, workflow design, and LLM systems.

Bringing ontology into a real business workflow is not a schema that a single team can create. Domain owners define business meaning, data and platform teams define sources, software and AI teams design tools and actions, and product and security teams clarify value and boundaries together. The AI/ML and data science teams contribute to retrieval and evaluation and measure how this model affects agent performance.

This is why ontology is not merely a graph database or modeling project. It is a living enterprise model, designed jointly by different teams to create a shared understanding of how the company works.

What is an AI agent?

An AI agent is a software system that observes its environment, plans, selects and calls tools, evaluates results, and changes its plan when needed to achieve a goal. The LLM is the reasoning component of this system; it is not the entire agent. Instructions, context, tools, permissions, memory, stopping conditions, and human approval are also part of the system.

A simple chatbot mostly generates a response to a question. An agent can, for example, read current information from a CRM, call a service, check the result, and choose the next step. The simplest agent loop looks like this:

Goal → observation → planning → tool call → result → validation → response or action

There is an important distinction here. If the steps and decision points are encoded in advance, the system is a workflow. If the LLM decides which tool to use and in what order based on intermediate results, it is an agentic system. In production, the two approaches often work together: use an agent where flexible decisions are needed and a workflow where the steps are critical and predictable. Anthropic’s distinction between workflows and agents and Google Cloud’s agent components explain this from different angles.

What is ontology?

A domain is a specific business area within a company, together with its concepts, relationships, and rules. Customers, orders, credit, and contracts are examples.

Ontology is a model that defines the concepts within a domain, the relationships between those concepts, their properties and states, and the constraints that apply to them in a shared, machine-interpretable form.

Put simply, an ontology answers these questions:

• What concepts and entities exist in our company?
• What do those concepts mean?
• How are they related?
• Which states and transitions are valid?
• Under what conditions may an action be performed?

Customer, Account, and Order are concepts. A customer owning an account is a relationship. An account being in an active, suspended, or pending state is a state model. Requiring email, phone, and identity checks before a customer is verified is a business rule. Starting a return or suspending an account is an action.

In the Semantic Web and academic contexts, ontology is a more formal concept. W3C’s OWL 2 standard treats ontologies as models containing classes, properties, individuals, and data values with formally defined meaning. In enterprise applications, every team does not need to use OWL or RDF; the core idea is to express the company’s business meaning explicitly in a shared model.

For a customer-verification domain, the model might look like this:

Is ontology the same as a schema and a knowledge graph?

These concepts are often mixed together in practice:

The boundary is not absolute. A knowledge graph can carry an ontology together with concrete facts, and an ontology can be implemented using a knowledge graph. As a useful simplification, ontology describes the possible concepts and relationships, while a knowledge graph often instantiates them with real entities. A knowledge graph may also carry schema and other semantic assertions.

None of this requires a separate graph database. Existing tables, event streams, services, and APIs can be bound to shared concepts. Graph technology is a storage and query choice. Ontology is a model of meaning.

Running a graph database does not mean you have an ontology. Having a schema does not mean you have modeled how your company thinks.

Why does ontology matter for AI agents?

When a chatbot misunderstands a concept, it produces a wrong sentence. When an agent misunderstands the same concept, it can select the wrong data, show information to the wrong person, or perform the wrong action.

Suppose you ask an agent:

How many users registered and became verified yesterday?

If the model interprets email_verified = true as “verified,” the result may be 312. But if your company’s definition of verification requires email, phone, and identity checks, the real number is 89. The query is technically valid but wrong for the business.

This error may not remain a reporting error. Leadership may use the wrong number for budgeting, operations for capacity planning, and finance for forecasting. A misinterpreted concept can become a company-wide decision within minutes.

RAG may retrieve a relevant document, but it cannot by itself guarantee which conflicting definition is current and authoritative. Text-to-SQL can translate natural language into tables and fields, but it cannot guarantee that the selected field matches the business definition. Tool calling can invoke the correct API, but it should not decide on its own whether the action is authorized for that user and context.

Ontology creates a shared foundation between these steps:

User intent → domain concept → canonical definition → authoritative source → rule and permission check → tool → evidenced response or action

This means the agent does not only ask, “Which table should I query?” It also has a systematic framework for asking, “Which concept does this word refer to in our company, which source is current, which relationships matter, and which preconditions apply to this action?”

The same model bridges answers and actions

When a user asks, “Can I suspend this customer’s account now?”, the agent must:

1. Resolve which customer and account the user means.
2. Find the current account state and relevant contract.
3. Check the preconditions for suspension.
4. Verify that the user is authorized to perform the action.
5. Obtain human approval when required.
6. Call only the authorized action handler.

Ontology defines the concepts and relationships in these steps. The authorization service checks permission, the policy engine evaluates the rule, and the action handler performs the actual change. This lets the model propose a plan without making it the sole authority for company policy or transaction boundaries.

What do current implementations show?

Enterprise products apply the ontology idea in different ways. Databricks Genie Ontology describes a context layer that extracts business terms, metric definitions, source authority, and business rules from tables, queries, dashboards, and connected applications. Snowflake’s Cortex Agents article examines adding ontology and a knowledge graph on top of a semantic view so agents can use hierarchies, synonyms, and domain constraints. Palantir’s approach extends the scope further and presents ontology as an operational layer that models data, logic, actions, and security together.

The common message is this: giving an agent more documents is not enough. The agent must know which concepts the company uses, which sources to trust, which rules to follow, and which actions it may call within which boundaries.

Ontology alone is not enough

Ontology defines the company’s world and its meaning, but it does not apply that meaning by itself. It does not retrain the LLM, update data, grant permission, call an API, or execute a transaction. It is not, by itself, an authorization system, policy engine, data-quality system, or transaction manager.

For example, ontology can define this:

A “verified customer” must have completed email, phone, and identity verification.

But a reliable agent needs answers to additional questions:

• Where is the customer’s current data?
• Which customer record are we actually referring to?
• Is that source current and trustworthy?
• May this user view the customer’s account?
• Is the user authorized to suspend the account?
• Which API or service should execute the action?
• Did the operation succeed, and who performed it?

That is why a reliable agent system roughly follows this flow:

Ontology → data access → rule and permission check → tool/API → transaction → audit record

Ontology answers “What does this concept mean?” and “Which relationships matter?” in that flow. The authorization system manages permission, the policy engine manages the business rule, the action handler performs the actual change, and the audit system preserves the evidence. Ontology does not suspend the account; the authorized service does. An agent may propose the right plan, but deterministic systems should perform the final check for critical operations.

A reliable enterprise agent needs at least these parts working together:

1. Business meaning: Concepts, relationships, synonyms, states, and exceptions.
2. Data bindings: Canonical sources, fields, freshness, ownership, and evidence.
3. Policies and permissions: Which operations the user and the agent may perform.
4. Tool and action contracts: Input types, preconditions, error behavior, and write boundaries.
5. Evaluation and audit: The correct answer, source selection, applied rule, and resulting action.

Critical state transitions, money movement, access changes, and similar operations must be rechecked deterministically in the authoritative systems. The agent may propose a plan and collect evidence; it must not bypass the rules of the system that performs the change.

Where should a company start?

Do not model the entire company at once. Choose one domain and workflow where a wrong action is costly: customer verification, refunds, contract renewal, or access approval.

1. Identify canonical concepts and definition differences across teams with domain owners.
2. Write down synonyms, identities, states, and exceptions explicitly.
3. Bind concepts to authoritative sources, freshness information, and evidence.
4. Give the agent a small number of clearly specified and safe tools.
5. Build an evaluation set from real questions; measure source selection and action decisions as well as answers.
6. Initially stage critical actions for human approval; expand autonomy gradually based on measured failures and override reasons.

This work often reveals an organizational problem before a technical one: sales, finance, and support may all use the word “customer” while referring to different populations. An agent will not resolve that disagreement. It will automate it.

Conclusion

LLMs bring general knowledge about the world. Agents can use that knowledge with tools, current data, and a planning loop. But they do not automatically know your company’s domains, domain rules, or the boundaries around critical actions.

Ontology makes the company’s own world machine-interpretable: it defines concepts, connects relationships, exposes rules, points to the right sources, and connects agent actions to safe systems.

Your model provider and agent framework may change. The meaning of a customer, the conditions that make a contract active, and the authority required to approve an operation are more durable. Reliable agent design starts by modeling this knowledge explicitly before choosing or changing the model.