Semantic layer or ontology? Your agents need both.

A semantic layer tells an agent how to count. An ontology tells it what exists and what it may do. One makes agents good analysts; the other lets them do the work. Here is the difference, and how the two fit together.

Constantine Yurevich · 3 October 2026 · 3 min read

Two words keep coming up when people talk about giving AI agents company data: semantic layer and ontology. They sound like the same idea from two different vendors. They aren't, and the difference decides whether your agents can only report on the business or can actually work in it.

A semantic layer answers "how much?"

A semantic layer is a set of definitions over your tables: dimensions to group by, measures to count. Revenue is the sum of paid invoices minus refunds. CAC is spend divided by new customers. Define each one once, and every app, report and agent gets the same number.

That matters because agents writing their own SQL get numbers confidently wrong. We wrote about the benchmarks: the same model that misses a share of questions against raw tables gets nearly all of them right through a semantic layer, and says "I can't answer that" when it can't.

But look at what a semantic layer actually knows. It knows totals. It doesn't know that this customer exists, that this deal belongs to that company, or that a deal can be moved to "won" by someone in sales. It reads. It doesn't change anything.

An ontology answers "what exists, and what can be done?"

An ontology is the company's model of itself. Palantir made the word popular in business software. CRMs like Attio call the same idea objects and attributes. It has three parts:

  1. Objects. The things the business runs on: customers, companies, deals, products, orders, contracts. Each one is a record with fields.
  2. Links. How the things relate: a deal belongs to a company, an order to a customer, a ticket to an account.
  3. Actions. What may be done to them, and by whom: move a deal, approve an order, issue a refund. Every change is kept in the history.

A CRM is an ontology with screens on top. So is an ERP. So is every back-office tool you've ever rented.

The simplest way to tell them apart

The ontology is the company's register: every customer, every deal, every product, item by item, with who may change what.

The semantic layer is the accountant: it counts totals over that register.

You need both, and they work best when one sits on top of the other. The objects are the nouns, and metrics are counted over them. "Revenue per customer segment" is a measure over orders, grouped by a field on the linked customer. When the metrics are counted from the same records people and agents edit, the dashboard and the CRM can't disagree.

Why agents need the ontology, not just the metrics

With only a semantic layer, an agent is a very good analyst. It can tell you pipeline fell this month and which segment drove it. Then a person opens another tool to do something about it.

With an ontology underneath, the same agent can do the work. Find the five deals that stalled, move the dead ones to lost, create follow-up tasks for the rest, and log why. It does that with the access of the person who asked, and every change is recorded. That is the step from agents that answer to agents that operate.

It also changes what's worth building. If customers, deals and orders already exist as objects you own, with actions and permissions handled, a CRM shaped exactly like your sales process is an app your agent can write in an afternoon. Renting one stops making sense.

What we're building

In SegmentStream Cloud the semantic layer has two halves: Objects, the ontology of your business, and Metrics, defined once and counted over them. Together with your data and your access rules, that's your company's context, in a workspace you own. Any agent connects through one connector, so switching agents doesn't mean rebuilding it.

Read more on the ontology page, or see how teams use it to own their CRM and their operations.

Want it for your company? Start a pilot: our engineers model your objects and build the first apps on your data in two weeks, at a fixed price. Self-serve opens to the waitlist this fall.

Enterprise pilot

Start a pilot.

Our forward-deployed engineers build one solution on your data, in your own workspace, as code you own. Tell us what you run today and what you want; your note goes straight to our founder.

  • One solution, on your data, in your own workspace
  • First version live in two weeks
  • Parity proven before anything is switched off
  • Fixed scope and price, credited to your contract if you continue

Not ready for a pilot? Send the form anyway with your question. An engineer will reply, not a sales rep.

How the pilot works

Goes to our founder’s inbox. No sales queue, no newsletter.

Your company’s software, built by agents, owned by you.

Start a pilot

Our engineers build the first version on your data in two weeks, at a fixed price.

Or join the waitlist for self-serve:

We’ll email you product updates, tips and onboarding help. Unsubscribe anytime.

Self-serve opens to the waitlist first.