Pillar 01 · Semantic Layer

The Hallucination Tax: What Your AI Pays for Not Knowing Your Business

MMMarcel MeyerJuly 20266 min read
counterpartytrademeaninginvoicecommodity

Connect an agent directly to your databases and document stores, and you've built something that looks complete on an architecture diagram — and behaves like a stranger in your building. Every request it handles pays a tax. Most teams never itemise it.

The tax, itemised

Ask an agent without semantic grounding a real business question — "what's our exposure to counterparty X?" — and watch what it actually has to do. It explores schemas. It samples tables. It guesses that cpty_id probably means counterparty. It infers, from column names and luck, how a trade relates to an invoice. Then it answers.

Three costs land on every single request:

Without a semantic layer, you have isolated data silos connected to agents that must find out for themselves where data sits and what it means — on every single request.

What a semantic layer actually is

A semantic layer is a machine-readable description of your business: what exists, what it means, and how it connects. We think of it as a data mesh with meaning — a weighted graph of semantics, built for AI consumption rather than human documentation. It works in three layers:

LayerWhat it describes
Business layerThe top-level view — business objects, capabilities, and domains, in the language the organisation actually uses.
Data ontologyHow things relate: a counterparty is party to a trade; a trade delivers a commodity and is billed on an invoice. Written down formally, this becomes a map the agent can follow.
Schema & named graphThe real tables, fields, and graph structures in source systems, tied back to the business meaning above — with lineage and access classification.

None of this is exotic. RDF(S) and OWL express the ontology; SHACL-style frameworks validate that real data conforms to it. The hard part is not tooling — it's the modelling discipline of writing down, precisely, how your business fits together.

The shift that matters: understanding before retrieval

The critical design decision is when the agent uses the layer. Done right, the semantic layer is consulted during reasoning, before data access. The agent first understands the territory — which sources are authoritative, how entities relate, which rules apply — and only then runs precise, targeted queries. Understanding precedes retrieval. That single ordering change is where most of the quality and cost gains come from.

The evidence

17% → 54%: on an enterprise SQL benchmark, giving the model a knowledge-graph view of the same database more than tripled correct answers — with the biggest gains on exactly the complex, multi-table questions your analysts actually ask [1].

98.2% vs 100%: a 2026 benchmark put a mid-tier model within two points of a frontier model on semantic-layer queries. Once the foundation is in place, model choice converges — and so does the bill [2].

How not to build one

The semantic layer is the least glamorous part of an enterprise AI system, and the one that decides whether the whole thing is any good. It will never demo as well as an agent that talks. It's simply the reason the agent's talk can be trusted.