Enterprises are investing billions of dollars in AI agents and infrastructure to transform business processes. However, in real-world applications, we see constrained success, often due to agents’ inability to truly understand business data, policies, and processes.
While we’re good at integrating with technologies like API management, Model Context Protocol (MCP) and others, having agents that truly understand the “meaning” of data in the context of a given company is a different story. Enterprise data is mostly housed in separate systems in structured and unstructured forms and must be analyzed from a domain-specific business perspective.
For example, the term “customer” may refer to a different group of people in a Sales CRM system compared to a financial system, which may operate this tag to pay customers. One department may define “product” as a SKU; another may represent a family of “products”; the third as a marketing package.
Data relating to ‘product sales’ therefore vary in meaning without agreed links and definitions. For agents to combine data from multiple systems, they must understand different representations. Agents need to know what data means in context and how to find the right data for the right process. Moreover, schema changes in systems and data quality issues during collection can lead to greater ambiguity and agents not knowing what to do when encountering such situations.
Additionally, the classification of data into categories, such as PII (personal information), must be strictly adhered to in order to comply with standards such as GDPR and CCPA. This requires data to be properly labeled and agents to understand and follow this classification. So we see that building a nice demo using agents is very doable, but getting it into production based on real business data is a completely different story.
Ontological source of truth
Building effective agentic solutions requires a single source of truth based on ontology. Ontology is a business definition of concepts, their hierarchy and relationships. Defines terms in relation to business domains, can aid establish a single source of truth for data, and capture uniform field names and apply classifications to fields.
The ontology can be domain-specific (healthcare or finance) or organization-specific based on internal structures. Defining an ontology is time-consuming at the beginning, but it can aid standardize business processes and lay a robust foundation for agent-based AI.
The ontology can be implemented using popular queryable formats such as triplestore. More sophisticated business rules with multi-hop relationships can operate labeled property graphs such as Neo4j. These charts can also aid companies discover novel relationships and answer sophisticated questions. Ontologies such as FIBO (Financial Industry Business Ontology) and UMLS (Unified Medical Language System) are available in the public domain and can be a very good starting point. However, they usually need to be customized to capture specific details of the business.
First steps with ontology
Once implemented, the ontology can be the driving force behind enterprise agents. We can now get AI to follow ontology and operate it to discover data and relationships. If necessary, we can create an agent layer that will provide key details of the ontology itself and discover data. Business rules and policies can be implemented in this ontology so that agents can follow them. This is a great way to ground agents and establish guardrails based on real business context.
Agents designed in this way and tuned to follow the ontology can stick to the guardrails and avoid hallucinations that may be caused by the immense language models (LLMs) feeding them. For example, a business policy may specify that if all documents associated with a loan do not have their validated flags set to “true”, the loan status should be kept in a “pending” state. Agents can bypass this rule and determine what documents are needed and search the knowledge base.
Here is an example implementation:
(Original figure by author)
As shown, we have structured and unstructured data processed by a document analysis agent (DocIntel) that populates the Neo4j database based on the business domain ontology. The data discovery agent in Neo4j searches for and queries the right data and forwards it to other agents supporting the implementation of business processes. Communication between agents takes place using a popular protocol such as A2A (agent to agent). A novel protocol called AG-UI (Agent User Interaction) can aid create more generic user interface screens to capture the actions and responses of these agents.
With this method, we can avoid hallucinations by forcing agents to follow ontology-based paths and maintain data classifications and relationships. Moreover, we can easily scale by adding novel resources, relationships, and rules 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 “client”, since the associated data about the hallucinatory “client” will not be verifiable during data discovery, we can easily detect this anomaly and plan to eliminate it. This helps the agent system scale with the business and manage its active nature.
Indeed, such a reference architecture adds some overhead to data discovery and graph databases. However, for a immense enterprise, it provides appropriate security and guides agents in coordinating sophisticated business processes.
Dattaraj Rao is the company’s innovation and R&D architect Durable systems.
Read more in our guest authors. You might also consider submitting your own post! See ours guidelines here.