Enterprises are investing billions of dollars in AI agents and infrastructure to transform business processes. However, in real-world applications, we see limited 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 really understand the “meaning” of information 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 have to be analyzed from a domain-specific business perspective.
For example, the term “customer” may refer to a different group of individuals in a Sales CRM system compared to a economic system, which can use this tag to pay customers. One department may define “product” as a SKU; one other may represent a family of “products”; the third as a marketing package.
Data relating to ‘product sales’ due to this fact vary in meaning without agreed links and definitions. For agents to mix data from multiple systems, they need to 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 information into categories, similar to PII (personal information), have to be strictly adhered to in order to comply with standards similar to 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, may also help establish a single source of truth for data, and capture uniform field names and apply classifications to fields.
The ontology could be domain-specific (healthcare or finance) or organization-specific based on internal structures. Defining an ontology is time-consuming at the starting, but it will probably help standardize business processes and lay a strong foundation for agent-based AI.
The ontology could be implemented using popular queryable formats similar to triplestore. More complex business rules with multi-hop relationships can use labeled property graphs similar to Neo4j. These charts also can help firms discover latest relationships and answer complex questions. Ontologies similar to FIBO (Financial Industry Business Ontology) and UMLS (Unified Medical Language System) are available in the public domain and could be a superb start line. However, they sometimes need to be customized to capture specific details of the business.
First steps with ontology
Once implemented, the ontology could be the driving force behind enterprise agents. We can now get AI to follow ontology and use it to discover data and relationships. If mandatory, we are able to create an agent layer that may provide key details of the ontology itself and discover data. Business rules and policies could be implemented in this ontology so that agents can follow them. This is a wonderful means to ground agents and establish guardrails based on real business context.
Agents designed in this manner and tuned to follow the ontology can stick to the guardrails and avoid hallucinations which may be caused by the large 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 needs to 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 writer)
As shown, we have structured and unstructured data processed by a document evaluation agent (DocIntel) that populates the Neo4j database based on the business domain ontology. The data discovery agent in Neo4j searches 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 similar to A2A (agent to agent). A brand new protocol called AG-UI (Agent User Interaction) may also help create more generic user interface screens to capture the actions and responses of those agents.
With this method, we are able to avoid hallucinations by forcing agents to follow ontology-based paths and maintain data classifications and relationships. Moreover, we are able to easily scale by adding latest resources, relationships, and rules that agents can mechanically follow, and control hallucinations by defining rules for the entire system reasonably than individual entities. For example, if an agent hallucinates an individual “client”, since the associated data about the hallucinatory “client” won’t be verifiable during data discovery, we are able to easily detect this anomaly and plan to eliminate it. This helps the agent system scale with the business and manage its dynamic nature.
Indeed, such a reference architecture adds some overhead to data discovery and graph databases. However, for a large enterprise, it provides appropriate security and guides agents in coordinating complex business processes.
Dattaraj Rao is the company’s innovation and R&D architect Durable systems.
Read more in our guest authors. You may additionally consider submitting your own post! See ours guidelines here.