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 truly understand business data, policies, and processes.
While we manage integration well with technologies like API management, Model Reference Protocol (MCP), and others, getting agents to truly understand the “meaning” of data in a given business context is a different story. Enterprise data is mostly locked in separate systems in structured and unstructured forms and needs to be analyzed with a domain-specific business lens.
For example, the term “customer” might refer to a different group of people in a sales CRM system than in a finance system that might use this tag to track paying customers. A department may define a “product” as a SKU; The second one can represent as "product" Family; A third as a marketing bundle.
Thus data about “product sales” vary in meaning without agreed upon relationships and definitions. For agents to combine 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 process. Additionally, schema changes in the system and data quality issues during collection can lead to greater ambiguity and the inability of agents to know how to act when faced with such situations.
Furthermore, classification of data into categories like PII (Personally Identifiable Information) must be strictly followed to maintain compliance with standards like GDPR and CCPA. This requires that the data be labeled correctly and that agents be able to understand and respect this classification. So we see that it is very possible to create a good demo using agents – but producing one by working on real business data is a completely different story.
Ontology-based source of truth
Building effective agentic solutions requires an ontology-based single source of truth. Ontology is a professional definition of concepts, their hierarchy and relationships. It defines terms in relation to the business domain, can help establish a single-source of truth for data and capture uniform field names and apply taxonomy to fields.
An ontology can be domain-specific (healthcare or finance), or organization-specific based on internal structures. Defining the ontology up front takes time, but it can help standardize business processes and lay a strong foundation for agentic AI.
Ontologies can be realized using common queryable formats such as TripleStore. More complex business rules with multi-hop relationships can use labeled property graphs like Neo4j. These graphs can also help enterprises discover new relationships and answer complex questions. Ontologies such as FIBO (Finance Industry Business Ontology) and UMLS (Unified Medical Language System) are available in the public domain and can be a very good starting point. However, these usually need to be customized to capture the specific details of an enterprise.
Getting Started with Ontology
Once implemented, ontologies can be the driving force for enterprise agents. We can now motivate AI to follow the ontology and use it to discover data and relationships. If necessary, we can provide key details of the ontology to an agentive layer and search the data. Business rules and policies can be enforced in this ontology for agents to follow. This is a great way to restrain your agents and establish guardrails based on actual business context.
Agents designed in this manner and conditioned to adhere to the ontology can cling to the guardrails and avoid hallucinations that may be caused by the large language models (LLMs) powering them. For example, a business policy may define that all documents associated with a loan have verified flags set. "Truth," The loan status should be kept in “Pending” status. Agents can work around this policy and determine what documents are required and raise questions based on the knowledge base.
Here is an example implementation:
(Original photo by author)
As illustrated, we have structured and unstructured data processed by a Document Intelligence (DocIntel) agent that populates a Neo4j database based on the ontology of the business domain. A data discovery agent in Neo4j finds and queries the right data and sends it to other agents handling the 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 create more generic UI screens to capture the workings and reactions of these agents.
With this method, we can avoid hallucinations by forcing agents to follow ontology-driven paths and maintain data classification and relationships. Additionally, we can easily scale by adding new properties, relationships, and policies that agents can automatically follow, and control hallucinations by defining rules for the entire system rather than individual entities. For example, if an agent hallucinates an individual ‘customer’, because the data linked for the hallucinating ‘customer’ would not be verifiable in data discovery, we can easily detect this anomaly and plan to eliminate it. This helps the agent system to drive the business forward and manage its dynamic nature.
Indeed, such a reference architecture adds some overhead to data search and graph databases. But for a larger enterprise, it adds the right guardrails and directs agents to streamline complex business processes.
Dattaraj Rao is an Innovation and R&D Architect Continuous system.
Read more from us guest authorOr, consider submitting a post of your own! see our guidelines here,
<a href