Enterprises are investing billions of dollars in AI agents and infrastructure to transform business processes. However, we are seeing limited success in real-world applications, often due to agents’ inability to understand business data, policies and processes.
While we manage integrations with technologies like API management, Model Context Protocol (MCP) and others, agents have to truly understand the “meaning” of data in a given business context. Enterprise data is often incorporated into various systems in structured and unstructured forms and analyzed with a domain-specific business lens.
For example, the term “customer” may refer to a different group of people in a sales CRM system, compared to a finance system that may use this tag for paying clients. A department may define a “product” as an SKU. Another can be represented as one "Products" family; A third as a marketing bundle.
Data on “product sales” thus vary in meaning without agreement on relationships and definitions. For agents to collect data from multiple systems, they must understand different representations. Agents need to know what the data means in context and how to find the right data for the right action. Additionally, schema changes in the system and data quality issues during collection can lead to greater ambiguity and inability of agents to know how to act when faced with such situations.
Additionally, maintaining compliance with standards such as GDPR and CCPA requires classification of data into categories such as PII (Personally Identifiable Information). This requires data to be labeled correctly and agents to be able to understand and respect this classification. So we see that creating a cool demo using agents is very doable – but putting it into production working on real business data is a different story.
An ontology-based source of reality
An ontology-based single source of reality by constructing effective agent solutions. Ontology is a business definition of concepts, their classification and relationships. It defines terms in relation to business domains, can help establish a single source of truth for data and capture uniform field names and apply hierarchies to fields.
An ontology can be domain-specific (healthcare or finance), or organization-based on internal structures. Defining the ontology up front is time-consuming, but can help standardize business processes and lay a solid foundation for agentic AI.
Ontologies can typically be realized using query formats such as the triple store. More complex business rules with multi-hop relationships can use labeled property graphs such as NEO4J. These graphs can also help businesses discover new relationships and answer complex questions. Ontologies such as FIBO (Finance Industry Business Ontology) and UML (Unified Medical Language System) are available in the public domain and can be a great starting point. However, they usually need to be customized to capture the specific details of an enterprise.
Getting Started with Ontology
Once implemented, an ontology can be a driving force for enterprise agents. We can now prompt AI to process the ontology and use it to discover data and relationships. If needed, we have an agent layer itself that can present the key details of the ontology and explore the data. Business rules and policies can be implemented in this ontology for agents to follow. It’s a great way to ground your agents and establish a guard based on a real business context.
Agents designed in this manner and designed to follow the ontology can stick to guardrails and avoid the power that large language models (LLMs) can cause. For example, a business policy may specify that all documents associated with the loan must have verified flags. "true," The loan status should be kept in “Pending” status. Agents can work around this policy and determine what documents are required and query the knowledge base.
Here is an example process:
(Original data by author)
As an example, we have processed and structured unstructured data through a document intelligence (documents) agent that populates the NEO4J database based on the ontology of the business domain. The data discovery agent in NEO4J finds and queries the right data and passes it on to other agents dealing with business process execution. Inter-agent communication occurs with popular protocols such as A2A (Agent to Agent). A new protocol called AG-UI (Agent User Interaction) can help build more generic UI screens to capture actions and responses from these agents.
With this approach, we can avoid illusions by implementing agents to follow ontology-driven paths and maintain data classification and relationships. Moreover, we can easily scale by adding new assets, relationships, and policies that agents can automatically comply with and control by defining system-wide rules instead of individual entities. For example, if an agent misleads an individual ‘customer’, because in data discovery the associated data would not be verifiable for a hallucinated ‘customer’, we can easily detect the anomaly and plan to eliminate it. It helps businesses manage the scale and dynamic nature of agentic systems.
Indeed, such a reference architecture adds some overhead to data discovery and graph databases. But for a large enterprise, it adds the right safeguards and directs agents to orchestrate complex business processes.
Dattaraj Rao is an innovation and R&D architect permanent system.
Read more from us Guest authors. Or, consider submitting a post of your own! See our Guidelines here.