Enterprises are investing billions of dollars in AI agents and infrastructure to rework business processes. Nonetheless, we’re seeing limited success in real-world applications, often resulting from the shortcoming of agents to really understand business data, policies and processes.
While we manage the integrations well with technologies like API management, model context protocol (MCP) and others, having agents truly understand the “meaning” of information within the context of a given businesis a unique story. Enterprise data is generally siloed into disparate systems in structured and unstructured forms and wishes to be analyzed with a domain-specific business lens.s
For instance, the term “customer” may discuss with a unique group of individuals in a Sales CRM system, in comparison with a finance system which can use this tag for paying clients. One department might define “product” as a SKU; one other may represent as a "product" family; a 3rd as a marketing bundle.
Data about “product sales” thus varies in meaning without agreed upon relationships and definitions. For agents to mix data from multiple systems, they have to understand different representations. Agents have to know what the info means in context and the best way to find the suitable data for the suitable process. Furthermore, schema changes in systems and data quality issues during collection can result in more ambiguity and inability of agents to know the best way to act when such situations are encountered.
Moreover, classification of information into categories like PII (personally identifiable information) must be rigorously followed to keep up compliance with standards like GDPR and CCPA. This requires the info to be labelled appropriately and agents to give you the chance to know and respect this classification. Hence we see that constructing a cool demo using agents may be very much doable – but putting into production working on real business data is a unique story altogether.
The ontology-based source of truth
Constructing effective agentic solutions requries an ontology-based single source of truth. Ontology is a business definition of concepts, their hierarchy and relationships. It defines terms with respect to business domains, may help establish a single-source of truth for data and capture uniform field names and apply classifications to fields.
An ontology could also be domain-specific (healthcare or finance), or organization-specific based on internal structures. Defining an ontology upfront is time consuming, but may help standardize business processes and lay a robust foundation for agentic AI.
Ontology could also be realized using common queryable formats like triplestore. More complex business rules with multi-hop relations could use a labelled property graphs like Neo4j. These graphs may also help enterprises discover latest relationships and answer complex questions. Ontologies like FIBO (Finance Industry Business Ontology) and UMLS (Unified Medical Language System) can be found in the general public domain and generally is a superb start line. Nonetheless, these often should be customized to capture specific details of an enterprise.
Getting began with ontology
Once implemented, an ontology could be the driving force for enterprise agents. We will now prompt AI to follow the ontology and use it to find data and relationships. If needed, we will have an agentic layer serve key details of the ontology itself and discover data. Business rules and policies could be implemented on this ontology for agents to stick to. This is a superb solution to ground your agents and establish guardrails based on real business context.
Agents designed in this fashion and tuned to follow an ontology can stick with guardrails and avoid hallucinations that could be attributable to the massive language models (LLM) powering them. For instance, a business policy may define that unless all documents related to a loan do not need verified flags set to "true," the loan status must be kept in “pending” state. Agents can work around this policy and determine what documents are needed and query the knowledge base.
Here's an example implementation:
(Original figure by Creator)
As illustrated, we’ve got structured and unstructured data processed by a document intelligence (DocIntel) agent which populates a Neo4j database based on an ontology of the business domain. An information discovery agent in Neo4j finds and queries the suitable data and passes it to other agents handling business process execution. The inter-agent communication happens with a preferred protocol like A2A (agent to agent). A brand new protocol called AG-UI (Agent User Interaction) may help construct more generic UI screens to capture the workings and responses from these agents.
With this method, we will avoid hallucinations by enforcing agents to follow ontology-driven paths and maintain data classifications and relationships. Furthermore, we will scale easily by adding latest assets, relationships and policies that agents can robotically comply to, and control hallucinations by defining rules for the entire system relatively than individual entities. For instance, if an agent hallucinates a person 'customer,' since the connected data for the hallucinated 'customer' is not going to be verifiable in the info discovery, we will easily detect this anomaly and plan to eliminate it. This helps the agentic system scale with the business and manage its dynamic nature.
Indeed, a reference architecture like this adds some overhead in data discovery and graph databases. But for a big enterprise, it adds the suitable guardrails and offers agents directions to orchestrate complex business processes.
Dattaraj Rao is innovation and R&D architect at Persistent Systems.
Read more from our guest writers. Or, consider submitting a post of your personal! See our guidelines here.
