Learn
What is a semantic layer, and what does an AI agent need from one?
A semantic layer is the set of business definitions that sits between your database tables and whoever is asking questions of them. It says what "net revenue" or "active customer" means in terms of the specific tables and filters behind it, so every dashboard and every query computes the number the same way.
Most companies already have one, whether or not they call it that. It might be a LookML project, a dbt Semantic Layer, a set of Snowflake semantic views, or a spreadsheet of metric definitions that one analyst keeps current. It works well enough while people are the ones asking. When an AI agent starts writing the SQL, the gaps show. The agent can't lean over and ask the analyst what a column means, so it guesses, and a guessed join returns a confident number that nobody can trace back.
A semantic layer turns business words into the SQL behind them
Take a simple question: what was net revenue last quarter? Before anyone can answer it, someone has to know a handful of facts that live nowhere in the schema:
- Revenue comes from order lines, not the invoice header, because the header counts split shipments twice.
- Refunds sit in a separate table and are matched on order ID.
- Test accounts and internal orders are excluded.
- "Last quarter" means the financial quarter, and the financial year starts on 1 April.
- Amounts are stored in paise, so they need dividing by 100.
A semantic layer writes those facts down once, in a form a tool can run. In rough pseudo-code (every product has its own syntax), the definition looks like this:
measures:
gross_revenue: SUM(order_lines.amount_paise) / 100
refunds: SUM(refunds.amount_paise) / 100
metrics:
net_revenue: gross_revenue - refunds
filters:
- customers.is_test = false
- orders.channel <> 'internal'
time: orders.booked_at, financial year starting 1 April
owner: Finance
Once that exists, a dashboard and an AI agent asking the same question get the same answer. When they don't, you know where to look.
What goes into a semantic layer
A working semantic layer usually holds:
- the business entities people talk about, such as customer, order, machine or loan
- metrics, and how each one is calculated
- dimensions to slice by, such as region or shift
- relationships between tables, including which side is "one" and which is "many"
- business rules and standard filters
- synonyms, so "GMV" and "topline" land on the same definition
Most semantic layers live in one of four places
- Inside a BI tool. Looker's LookML model is the best-known example. The definitions serve that tool well and other tools less well.
- As a standalone layer between the warehouse and every tool. Cube and AtScale work this way.
- Next to your transformation code, as with the dbt Semantic Layer.
- Inside the warehouse, through Snowflake semantic views or Databricks metric views.
Each of these needs someone to write and maintain the definitions. The warehouse vendors have started drafting them for you. Snowflake's Semantic View Autopilot proposes semantic views from SQL examples and query history, and Databricks describes Genie Ontology as a knowledge graph built from governed tables, past queries, dashboards and notebooks. We read that as a sign of where the category is going: definitions written entirely by hand can't keep up with how fast AI agents ask questions.
An AI agent needs more from a semantic layer than a dashboard does
A dashboard is built once, by a person who knows the data, and if a number looks off someone usually notices. An agent writes fresh SQL for every question. What it can see is table names and column types, and a type only tells you the shape of a value. It says a column holds a decimal. It doesn't say the decimal is in paise, or that two columns both called product_id come from different systems and have nothing to do with each other.
So a semantic layer for AI needs a few things most BI-era layers leave out:
- Joins marked as declared in the schema or inferred from the data, with the evidence for each inferred one.
- Rules a result must pass before anyone sees it. A percentage of time can't exceed 100%, and a per-machine report can't return more rows than there are machines.
- Memory of corrections, so a mistake fixed on Tuesday stays fixed on Friday.
- The SQL your team already trusts, as worked examples the agent can follow.
Without these, an agent on a real company database is guessing politely. With them, it can check its own work before it hands you a number.
The hard part is building it, and keeping it current
Every new metric, renamed column, new source system or changed business rule means someone edits the model. On a large estate the first build is the slow part. A team of two to four analysts and engineers typically needs three to six months to understand a 2,000-table database well enough to write those definitions.
This is where a lot of AI-analyst rollouts stall. One small data team described it on r/analytics: their AI tool was useless on columns named like dt_crtd_ts, and they ended up spending more time writing column comments than getting answers. The tool needed a semantic layer, and nobody had time to build one.
Antcluster builds the semantic layer from the database you already run
Antcluster connects read-only to your relational databases, works out what the tables mean, and gives people and AI agents a layer they can query and correct. Here is what that lets a team do.
Ask what the business already knows
Ask "net revenue by region last quarter" in plain language and get the answer with the SQL and the records behind it. You don't hand-build a semantic layer first, and nobody writes SQL for each new question.
Write down what only a few people know
Some of the most important definitions were never recorded anywhere: that region code 7 was folded into region 4 two years ago, or that the invoice table double-counts split shipments. Antcluster proposes these from profiles of the data and from SQL your team already trusts. It keeps declared foreign keys apart from inferred joins and shows the evidence and confidence for each inferred one. An engineer approves or rejects, and approved meanings become part of the layer.
Look for connections nobody has made yet
Once meanings are connected across tables, you can ask questions no one had thought to ask, such as whether refund rates rise for customers whose orders ship from one particular warehouse. Antcluster returns these as candidates with their evidence, for your team to test before anyone acts on them.
Why this is possible now
Software went through this first. Agent harnesses like Claude Code changed what a small engineering team will take on: a few engineers can now attempt work that used to need a large team, like porting a whole console game to PC or writing GPU shaders in a short window. A harness is the working environment around the model, meaning the tools and context it can use plus the feedback that tells it when it's wrong. Code gives an agent plenty of that feedback. Interfaces, types where the language has them, tests and a build that fails loudly all connect what an engineer meant to something an agent can check.
Company data has very little of that. The database knows a column is a number. It doesn't know what the number means or which other table it belongs with, and that knowledge sits with a few people. A semantic layer that builds itself, and that your engineers can review, gives data work the footing code already has.
We call the result escape velocity: less effort rebuilding context before each question, and more room to follow the next one. A data team gets time for the use cases that never reached the top of the backlog. A finance or operations lead gets to ask directly instead of filing a request. That holds in a twenty-person company and in a group running fifty systems, and in both it leaves room to find new uses for the data and to catch risks nobody had thought to look for.
It keeps learning as you use it
The database, the agent and the layer move together. Each investigation can leave behind a reviewed definition or a corrected join, and the next question starts from there. The ontology underneath is written in OWL 2 and expands itself as new tables and approved findings arrive, while an engineer reviews what changes. Questions your team has settled get the same logic every time. New questions come back with their assumptions listed, so you can tell exploration from an agreed answer.
What this looks like in practice
Understanding a 2,000-table database usually takes a team of two to four people three to six months. Antcluster gets to a working map of what those tables mean in a single day, ready for your engineers to review.
See the semantic layer Antcluster builds on your data
Connect one database read-only, inside your own network if you prefer, and bring a set of questions your team already knows the answers to. We'll show you the layer Antcluster builds and score its answers against yours.
Questions people ask about semantic layers
Is a semantic layer the same as a semantic model? Close enough that people use the terms interchangeably. "Semantic model" often means the definitions inside one BI tool. "Semantic layer" usually means definitions shared by every tool that queries the data.
Do I need a semantic layer for text-to-SQL? On a small, well-named schema you can get by without one. On a real company database the model needs to know which joins are real and which filters apply, or it writes valid SQL that returns the wrong number. More in why text-to-SQL gets joins wrong.
Is a semantic layer the same as an ontology? They overlap. A semantic layer maps metrics to SQL. An ontology describes what things are and how they relate, with rules attached. See ontology vs semantic layer vs knowledge graph.
Does Antcluster replace my BI tool or dbt? No. Your dashboards and models stay where they are. SQL your team already trusts, from saved reports or views, is one of the things Antcluster learns from.
Where does my data go? Antcluster reads your database through a read-only connection and can run on your own infrastructure. The one outside component is the language model, which you pick from the ones we support, and on-premises setups keep model traffic inside your network.