Skip to content
Tech

Author Becomes Excited About Semantic Layer

2 November 2026 Semantic layer · Agents Original on LinkedIn

For the last few months, a core focus area for us has been figuring out semantic layer and ontology design and implementation, and helping clients with it. I’m personally very excited about developments in this field.

Most enterprises are knee-deep in AI use case implementations, and some are even approaching enablement systematically, with a structured AI framework. But value realization from AI is slower than expected.

The software development lifecycle is one area where AI tools are really making an impact. Coding harnesses in combination with better and better models do accelerate coding, and smaller teams are able to improve productivity in a meaningful way, but large IT teams across enterprises get bogged down very quickly. Even if you can churn out code ten times faster, getting the change deployed to production is as slow as ever: review cycles, approval boards, cross-team, cross-program and cross-enterprise dependency management, and negotiations over APIs and data are not yet benefiting from LLM technology to the same extent.

Many of our clients recognize that there has to be a way to realize value faster. They want to be able to build agentic workflows now, and not be held up waiting for data and API modernization workstreams, release calendar dependencies and cross-program technical negotiations. And when it comes to empowering AI agents to execute workflows, LLMs do not know what a policy, a claim, a client or a store means in a particular company, which numbers are authoritative, who may see what, and which actions are permitted. A governed business ontology supplies that: the objects of the business, the links between them, the approved metrics, the rules, the permissions, and the actions a person or an agent may take.

The tech industry is now aligning around the concept of a semantic layer as one of the key enablers for this need. Semantic layers add an abstraction, a so-called ontology model of the business, on top of the existing data and service estate, serving new agentic workflow orchestrations as well as new “regular” applications. They define what an “order” and a “delivery address” mean for the e-commerce capability of the business, and they enable agentic or regular business workflows to be developed rapidly on top of this well-defined model.

Diagram: agents, applications and people sit on top of a business ontology made of objects, links, metrics, rules, permissions and actions, which sits above the existing estate of core systems, lakehouse, SaaS, APIs and documents. Actions is drawn dashed.
Agents and applications work against business objects. The systems underneath stay where they are.
Palantir was the pioneer here, bringing the ontology approach into the enterprise with its Foundry platform and assigning “forward deployed” engineers, working directly with business stakeholders, to build workflows and deliver value quickly on top of this abstraction. It remains the reference point today. As LLMs and agentic workflows spread across businesses, many other vendors are now moving to provide similar capabilities, integrated into their own data platforms. Microsoft’s Fabric IQ Ontology is in public preview. It sits within Fabric IQ, the semantic intelligence and context layer inside Microsoft Fabric that translates technical database tables into the language of the enterprise. Databricks is also in public preview with its own ontology product, Databricks Genie Ontology. Genie Ontology is the unified context layer that gives the Genie family of AI experiences a business-aware map of the enterprise. Both products aim to integrate with the broader data platform offerings from these Tier 1 platform vendors. There are also established independent products such as Denodo, whose data virtualization platform adds a semantic layer and takes a “zero-copy” approach, leaving data in place and aggregating it into business views.

Many of these newer ontology offerings bring structure, intelligence and definition to agentic workflows, providing essential grounding in the enterprise and the inner workings of the business. What they do not yet offer is a standard pattern for the “action” layer: how to act on the aggregated information once it is in front of agents and human end users. Palantir, by contrast, has a clear strategy around the kinetic aspect of moving from data to action.

There’s plenty of platform activity, and as an implementation partner, my company is doing a good deal of work supporting clients in this direction. We are making our blueprints available to our clients and consulting on the approach, but also bringing in some pre-built ontologies and accelerators as a starting point, particularly in domains where industry-standard ontologies make sense. We can then create the pipeline to implement the model on the specific underlying platform. Given that gap, I see our role as defining the action capability for our clients’ use cases, as well as figuring out the best user experience layer for interacting with the agentic workflows and the intelligence coming from them.

It’s also a fast-moving, fast-changing area, with considerable fluidity even from a conceptual perspective. Even the definition of a semantic layer is evolving: from a translation map that calculates a number for a dashboard into a business model that agents and applications work through.

Table of three generations of the semantic layer: the BI semantic layer for analysts and dashboards, the AI context layer for conversational agents, and the operational ontology for agents that act and application developers.
The term covers three different things. Most of the market debate is about the second.
I’m personally having a lot of fun with this topic. I fondly remember a very active period in my career, during the “XML wave” of enterprise tech, when we had similar conversations and dove into ontologies and semantic views. The same discussions were emerging around defining standard industry- and domain-specific schemas, arguing about schema languages, and working with a diverse set of emerging tools that promised to bring this into the enterprise. OWL, XML Schema, XSLT: this was my playground. Clearly, as engineers, we need to gear up to engage with businesses, map out the structure of the use cases we are supporting, and model a clean, usable and reusable schema. Data modeling, event storming, and working with data catalogs and dictionaries are becoming essential skills for practicing engineers. I’m already eyeing some of the open-source tools I can try, alongside the Tier 1 platform offerings.

Ping me if your enterprise needs help in this area. Alongside knowledge graphs, I’ll definitely dedicate my coding time to this topic for the next few months. I’ll keep reporting on this journey here.