Ontology-Driven Enterprise Data Agents: From Retrieving Numbers to Explaining Why

Every enterprise wants an AI that can answer questions about its data: ask a question in plain language, retrieve business performance data, and get a clear analysis of the issue.

To help AI understand their business, many teams first organize metrics, calculation definitions, and documentation. They then use retrieval-augmented generation (RAG) to find relevant content and pass it to a large language model to generate an answer.

This approach is quick to implement and valuable for finding information and summarizing text. In enterprise conversational analytics, however, we have seen two recurring problems: questions about “how much” may be answered using the wrong metric definition, and once the numbers are retrieved, the system struggles to explain “why.”

These problems cannot be solved simply by switching to a more capable model. Before answering, the model needs access to relevant business knowledge. If it receives only a few similar passages, without knowing where a metric applies or how business objects relate to one another, it is difficult for the model to piece together the full picture on its own.

Two Problems: Picking the Right Metric and Answering "Why"

The first problem is picking the right metric.

Suppose a business user asks, "What were sales last month?" The enterprise's metric catalog may include sales, net sales, sales including tax, and sales after refunds. Their names are similar, but the resulting figures may differ.

If the system retrieves metrics solely by how closely their names match the question, it may select a definition that looks reasonable but does not reflect the user's intent. Worse, the answer may not look obviously wrong: a figure calculated using the wrong definition can still appear perfectly plausible.

Banking presents a similar challenge. When a manager asks, "How is the business performing?" they may want a set of metrics: general deposit balances, loan balances, net profit, fee and commission income, and so on. These metrics may not closely resemble the phrase "business performance," yet together they represent what business users understand that phrase to mean.

Similarity is not the same as business relevance. To select the right metric, the system also needs to know which business area it belongs to, where it applies, and how it is calculated.

The second problem is answering "why."

When an operations manager sees that sales in East China have declined, they are likely to ask, "Why did sales fall? Which customers and product categories contributed to the decline?"

At this point, finding a sales metric is no longer enough. The agent needs to know that sales can be broken down by region, channel, product category, and customer. It also needs to connect the relationships among regions, customers, orders, and products.

If knowledge is presented only as isolated document fragments, "customer" may appear in one passage and "order" in another, without their business relationship being expressed in a form the agent can directly use. Finding relevant content does not necessarily tell the agent what to investigate next.

This is a common problem we have observed in customer deployments: when the structure and relationships within business knowledge are not preserved, the agent either selects the wrong definition from several similar alternatives or does not know which path to follow when asked "why."

Ontology: Organizing Scattered Business Knowledge into a Graph

Our approach is to establish a semantic structure organized around the business between the enterprise’s underlying data and its AI applications. We call this an ontology.

An ontology can be understood as a business map. It needs to clearly describe which places exist, which roads connect them, what characteristics each place has, and which calculations can be performed there.

This does not require physically moving all enterprise data into one location. Instead, it organizes existing data and knowledge into a business representation that an agent can understand and trace back to its sources.

In our work, this graph consists primarily of four elements:

• Business objects are the nodes in the graph. Customers, orders, products, accounts, and deposits are all objects that business users recognize. A single object may map to multiple tables, but business users should not have to learn the names of those tables first.
• Business relationships are the edges between nodes. Customers place orders, and orders contain products. Customers open accounts, and accounts are associated with deposits. These relationships connect previously scattered data into understandable business paths.
• Business attributes describe the objects. Customers have tiers and regions; orders have statuses and amounts. These attributes help an agent understand what information an object can provide and distinguish between similar concepts.
• Metric definitions specify the calculation rules behind the numbers. How sales are calculated, which orders must be excluded, and which components make up a deposit balance all determine what the final figure means.

Together, these elements give AI more than a collection of scattered table names, fields, and document fragments. It can first determine which business object a question concerns, then inspect that object’s attributes, relationships, and metric definitions to progressively locate the data needed for an answer.

In practice, physical relationships must also be distinguished from business relationships. Two fields that appear joinable do not necessarily form a relationship that makes sense in business terms. Objects, relationships, and metric definitions all need to be validated against the enterprise’s actual business practices.

Choosing the Right Metric: Understand Its Business Definition, Then Narrow the Search

With this map in place, the first step is to address incorrect metric selection.

Returning to the sales example, when several metrics have similar names, the agent should not ask only, “Which name is the closest match?” It should also examine each metric’s business definition: what it covers, which orders it includes or excludes, which type of business object it belongs to, and whether it applies to the current question.

This information serves as the metric’s “identity.” When a user asks for an overview of regional business performance, the agent can check candidate definitions against the region, time period, and business context in the question. If the intended definition remains ambiguous, it should seek clarification rather than guess at the most plausible-looking answer.

The next step is to narrow the search progressively. Enterprises may accumulate large numbers of metrics. When they are presented as a flat list, similar names can easily create confusion. If metric definitions are organized by business object and business domain, the agent can first locate the relevant business area, then explore the corresponding objects and metrics, narrowing the candidates step by step.

In the banking example, a user might ask, “What is the personal demand deposit balance at a particular branch?” The agent can first locate the deposit object and inspect the definition and calculation rules for personal demand deposits. It can then follow the relationship between accounts and organizational units to identify the branch filter before generating the query.

This process requires understanding both “personal demand deposits” and how “a particular branch” maps to the data.

The goal is not to guarantee that AI will never select the wrong metric. It is to give the agent more business information to check and make its selection process open to inspection.

Answering “Why”: Letting the Agent Explore Business Relationships

Selecting the right metric is only the first step. When users ask why something declined, the agent must continue its analysis along the relevant relationships.

We want the agent to do more than receive a single set of retrieval results and assemble an answer from the available material. It should be able to inspect the available business objects, determine which metric definition needs checking, and follow relevant relationships to discover dimensions for analysis.

If a lead does not fit, it can return to other candidates. If several directions look promising, it can explore and compare them separately.

The information provided to the model must cover the question sufficiently without loading all available knowledge into the context at once. Our approach is to organize context incrementally through the ontology: at each step, provide the objects, attributes, relationships, and metric definitions needed for the current decision.

For the question “Why did sales in East China decline?” one possible analysis path is:

1. Confirm the metric. Use the region and time period in the question to check which sales definition applies and whether the calculation includes factors such as refunds.
2. Identify dimensions for analysis. Starting from the business objects associated with the metric, determine which dimensions are available, such as region, channel, product category, and customer.
3. Compare across dimensions, then drill down. Follow business relationships among regions, orders, products, and other objects to compare changes across dimensions and identify the largest contributors to the overall change.
4. Validate against the data. Examine the relevant orders, refunds, or customer records in more detail to provide evidence that business users can verify.

Suppose the analysis finds that changes in refunds for a particular product category in the online channel are associated with the overall decline. The agent can present this finding and its supporting data, helping business users decide what to investigate next.

This example illustrates an analytical method. It does not mean that a relationship graph can automatically establish causality. Correlation, contribution to a change, and the underlying business cause represent different levels of judgment. They still need to be verified against metric definitions, detailed data, and business rules.

When we describe a shift “from finding similarities to taking action,” we primarily mean that the agent can actively explore, search, and analyze through the ontology. This does not imply automatically performing business operations with external consequences. Writing data or triggering workflows still requires appropriate permissions, approvals, and auditing.

How Does This Graph Take Shape in DataPilot?

At this point, many readers may ask: if an ontology needs to describe objects, relationships, attributes, and metric definitions, must we map the entire enterprise before we can start using it?

Our practice is to begin with a clearly bounded business scenario. We bring together existing data and knowledge around that scenario to create an initial model, then have business users validate it through real questions.

As usage and feedback grow, the model is progressively corrected. Once individual business domains mature, we can explore how to reuse their semantics across domains.

Generate an Initial Draft from Existing Assets

Enterprises usually have substantial material to work with: table schemas, field types, primary and foreign keys, sample data, knowledge base documents, historical SQL, BI dashboards, and calculation logic in ETL processes.

Different materials provide different clues. Table names, fields, and sample values help identify potential business objects and attributes. Foreign keys and similar information provide clues about relationships. Knowledge bases, historical SQL, and ETL processes may preserve more explicit rules, such as metric filters and business calculation logic.

For example, a sales definition may require excluding test orders or canceled orders. Such rules may not be apparent from field names, but they may already be documented in enterprise materials or historical queries.

During modeling, we need to combine these clues, map them to business objects and metric definitions, and preserve their mappings to the underlying data.

Large language models and agents can help organize these materials, reducing the work required to start from scratch. But what they produce is an initial draft: they may misinterpret fields, omit conditions, or mistake physical joins for business relationships. The draft must therefore be validated by business experts.

Validate and Refine Through Real Questions

Having experts inspect a graph directly is one option. Testing it with real questions is often more intuitive.

Business users can ask questions they frequently encounter, then examine which metric definitions the agent selects, which relationships it follows to find data, and whether its answers align with their understanding of the business.

When errors occur, experts can identify whether the problem lies in an incorrect metric definition, a flawed relationship path, or a missing business condition.

This process can also uncover tacit knowledge. Some rules are not documented but exist in the minds of experienced employees—for example, which records a metric should exclude in a particular scenario, or what should be checked first when an anomaly occurs. Questions and corrections create an opportunity to capture this knowledge.

However, a single piece of user feedback may not apply to every department or every time period. We place greater emphasis on treating feedback as a lead that requires confirmation, clarifying its scope of applicability, and allowing business users to decide how shared semantics should be updated.

Usage helps expose problems, but it cannot replace judgment about whether the knowledge is correct.

Why We Do Not Start with One Enterprise-Wide Graph

Once a subdomain ontology can support real business needs, the natural next question is whether multiple scenarios can be connected to create a broader understanding of the business.

This is indeed a direction we are exploring. But attempting enterprise-wide modeling from the top down at the outset can easily lead to several problems.

The first is excessive abstraction. To reach agreement, different departments might define a customer as “an entity that has a commercial relationship with the enterprise.” This is not wrong, but it is too broad. Specific scenarios such as retail deposits, corporate lending, and risk management still require distinct objects and rules.

The second is the high cost of alignment. Repeated cross-departmental meetings can help clarify disagreements, but without concrete questions to guide the discussion, it may remain at the conceptual level. Business teams may wait a long time before seeing their own problems addressed.

There is also the problem of becoming static. Businesses change, and so do metric definitions. If an ontology is treated as a one-time project, without continued use and maintenance after completion, it may gradually drift away from reality.

We therefore prefer to start locally: let one subdomain solve real problems first, then explore cross-domain relationships and reuse based on validated knowledge.

Shared concepts require both recognizing common ground and preserving differences. Objects with the same name cannot simply be merged into one.

Our long-term direction is to progressively bring together the semantics of multiple business subdomains and explore how new scenarios can reuse existing knowledge. This still requires continued practical work. It should not yet be interpreted to mean that all subdomain ontologies can be merged automatically, or that a newly connected agent will inherently understand the entire enterprise.

From Finding Similarities to Finding Paths

Models will continue to become more capable. But enterprise business definitions, data relationships, and analytical expertise will not automatically become clearer as model capabilities improve.

For enterprise Data Agents, retrieving numbers is only the first step. Going further requires choosing the right metric definition, knowing where to find evidence, analyzing along business relationships, and allowing business users to see how a conclusion was reached.

Our approach to ontology-driven Data Agents is to organize this scattered business knowledge so that the agent has paths to follow, then let the map evolve with the business through concrete scenarios, expert validation, and ongoing feedback.

Start with a question that frequently leads to a follow-up “why.” Clearly define the relevant objects and metric definitions, establish a verifiable analysis path, and refine it progressively based on errors encountered in use.

Making the answer to one question more reliable is more valuable than drawing a graph of the entire enterprise at the outset.