Knowledge Graph and Semantic Layer: why one definition of 'customer' changes how every agent reasons

A demo question that breaks most enterprise AI: "How many customers do we have?"

CRM counts accounts with at least one open opportunity. ERP counts billing entities with an active invoice in the last 12 months. BI counts unique payer IDs from the warehouse. Three answers. All correct. None equal.

The AI inherits the inconsistency. Whichever data source it queries first, that becomes "the truth." The next question on the next channel will give a different one.

The cross-module reasoning problem

The root cause is not bad data. The root cause is missing semantics. Every module has a slightly different definition of every shared concept, and there is no neutral place to reconcile them. Custom extracts, weekly committee meetings, manual reconciliations - companies build a layer of human glue to compensate.

For a Cash Position agent that needs to reason across receivables (ERP), open opportunities (CRM), payroll commitments (HCM) and supplier obligations (Procurement), the glue has to live in the platform itself.

RDF/OWL plus a property-graph adapter

DivetIQ's Knowledge Graph encodes the shared meaning once. The entities are the obvious ones - customers, suppliers, employees, assets, contracts, documents - plus the operational ones - KPIs, processes, controls, agents. The relationships between them are typed and queryable.

The implementation is dual-format on purpose. The RDF/OWL graph with a SPARQL endpoint handles ontological queries: "which controls cover this regulation in this entity?" The property-graph adapter handles traversal: "which customers depend on the supplier we just downgraded?" Same store, two access patterns.

On top of the graph sits the semantic layer - the place where business measures are defined. A semantic object for "active customer" lives once, is versioned, and is consumed by every downstream surface: Power BI, Tableau, Excel, the conversational analytics agent, the embedded analytics SDK, and every specialist agent in the catalog.

How agents and conversational analytics share one layer

The user asks "how many customers do we have?" in plain language. The conversational analytics agent does not generate SQL from scratch. It resolves the question against the semantic layer first, identifies the relevant semantic object, and compiles a query that respects its definition. The answer comes back with the semantic object name, its version, and the row counts the answer was computed from.

The same semantic object is what the Pipeline Health, Customer Health and Subscription Revenue agents reason over. When the CFO asks the conversational agent and the COO opens the BI dashboard, they see the same number, because both are downstream of the same definition.

That is the difference between AI that demos well and AI that survives a quarterly audit. The semantic layer is the load-bearing structure. The agents are downstream consumers. The graph is the contract between them.