Enterprises are investing billions of dollars in AI agents and infrastructure to transform business processes. However, success in real-world applications is often limited due to agents’ inability to truly understand business data, policies, and processes.
We use API management, Model Context Protocol (MCP), and other technologies to successfully manage integrations, but enabling agents to truly understand what the data “means” in the context of a specific business is a different story. Most enterprise data is siled into disparate systems in structured and unstructured formats and must be analyzed with a domain-specific business lens.
As an example, the term “customer” may refer to a different group of people in a sales CRM system compared to a finance system that uses this tag to make payments to customers. A department may define a “product” as a SKU. Another can be expressed as "product" family; third as a marketing bundle;
Therefore, data about “product sales” has different meanings without an agreed relationship or definition. 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. Furthermore, schema changes in the system or data quality issues during collection can further increase ambiguity and leave agents unsure of how to act when encountering such situations.
Additionally, maintaining compliance with standards such as GDPR and CCPA requires strict adherence to the classification of data into categories such as PII (Personally Identifiable Information). This requires that the data is labeled correctly and that the agent is able to understand and respect this classification. So while it turns out that building a cool demo using agents is very doable, getting it up and running with real business data is a whole different story.
Ontology-based source of truth
Building effective agent solutions requires a single, ontology-based source of truth. An ontology is a business definition of concepts, their hierarchies, and relationships. It helps you define terminology for your business domain, establish a single source of truth for your data, obtain uniform field names, and apply classification to fields.
Ontologies can be domain-specific (healthcare or finance) or organization-specific based on internal structure. Predefining an ontology is time-consuming, but it helps standardize business processes and lays a strong foundation for agentic AI.
Ontologies can be realized using common queryable formats like triplestores. More complex business rules with multi-hop relationships can use labeled property graphs like Neo4j. These graphs also help companies 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 are a great starting point. However, these typically need to be customized to capture specific details for your company.
Get started with ontology
Once implemented, an ontology has the potential to power enterprise agents. You can now encourage AI to follow ontologies and use them to discover data and relationships. Optionally, you can have the agent layer provide important details of the ontology itself and discover the data. Business rules and policies that agents follow can be implemented in this ontology. This is a great way to ground agents and establish guardrails based on real-world business context.
An agent designed this way and tuned to follow an ontology can adhere to guardrails and avoid illusions that can be caused by large-scale language models (LLMs) that power the agent. For example, a business policy could define that unless all documents associated with a loan have the verified flag set: "truth," The loan status must remain in a “pending” state. Agents can bypass this policy to determine what documents they need and query the knowledge base.
An example implementation is shown below.
(Original figure by the author)
As shown in the diagram, there is structured and unstructured data processed by a Document Intelligence (DocIntel) agent that populates the Neo4j database based on the business domain ontology. Neo4j’s data discovery agents find and query the appropriate data and pass it on to other agents that handle business process execution. Communication between agents is done using common protocols such as A2A (Agent to Agent). A new protocol called AG-UI (Agent User Interaction) helps build more generic UI screens to capture behaviors and responses from these agents.
This method avoids illusions by forcing agents to follow ontology-driven paths and maintain data classifications and relationships. Furthermore, it is easily extended by adding new assets, relationships, and policies that agents can automatically comply with, and illusions can be controlled by defining rules for the entire system rather than individual entities. For example, if an agent hallucinates an individual “customer”, this anomaly can be easily detected and a plan to eliminate it, since the connection data of the hallucinated “customer” cannot be verified with data discovery. This helps the agent system scale with your business and manage its dynamic nature.
In fact, such a reference architecture adds some overhead for data discovery and graph databases. But for large enterprises, appropriate guardrails are added and agents are given direction to orchestrate complex business processes.
Dattaraj Rao is an innovation and R&D architect. Persistent system.
read more guest writer. Or consider submitting your own post. See our Click here for guidelines.
