Semantic layer for AI agents: do you need one, or do you already have it?

The short answer

No, you do not need to buy a semantic layer to use an AI agent on your data. An AI agent, here, is an assistant such as Claude or ChatGPT that can look up figures in your company’s data. What you need is each important number written down once, with what it counts and what it leaves out, in a place the AI reads. A semantic layer is one such place; there are four others.

A plain total is a fair place to start; breakdowns are where to check. Our two tests on demo data showed that; details below.

If you already have one, use it and add nothing. Connecting the AI is the short step. Agreeing what “revenue” means with the people who use the number is the long step, and no option here shortens it.

What a semantic layer is, and why you are being told to get one

A semantic layer is one place where each number is defined once, so that every tool asks for it by name. What a semantic data model is separates it from two terms that sound alike.

Most pages that rank for this question come from companies that sell one. Cube, which sells one, states the condition itself: “For a prototype or an analyst-only SQL assistant, you can start without one” (Cube). Vendor pages read 9 to 11 October 2026.

What an AI agent needs from your data

Left alone with table and column names, an AI agent picks its own meaning of each word. Four things take the guessing out:

1. A written meaning for each number. What it counts and what it leaves out.
2. Declared joins. Which tables connect, and on which key.
3. A boundary. A list of what the agent may read and, where the tool allows it, no way to write a query around 1 and 2.
4. A record. What was asked, and the query that ran.

A definition card for net revenue, filled in from our demo store’s Purchases Data Mart:

• Name: Item Net Revenue (line_net_revenue)
• What it counts: “Revenue recognised only for Completed orders”
• What it leaves out: cancelled and returned orders, which count as zero
• One row is: one product bought within an order
• Joins to orders on: order_id
• Who decides when it changes: a named person
• Last changed: a date

Teams skip the last two lines; they are what “owning a definition” means: you decide when it changes, agree the change with the people who use the number, and write it where the tool reads it.

Five places the definitions can live

What separates them on paper is whether the agent is only told your definitions and still writes its own query, or is held to them: handed definitions to choose from, with no way to write a query of its own. We ran two rows ourselves; the last column says which.

One thing to check in row 4. Switching dbt’s AI features off hides one SQL tool only: “text_to_sql is the only tool hidden and every other tool keeps working” (dbt documentation). execute_sql stays, so the agent is held only when it has no SQL tool at all.

Row 5 is ours. The analyst publishes an existing query, table or view as a Data Mart in OWOX Data Marts, describes each field and declares the joins. Agents on the OWOX MCP server “cannot run arbitrary SQL” (OWOX documentation). Two limits: it is one more place to keep current, and “the resulting data rows and totals are sent” to the company behind the agent. OWOX’s MCP server is part of OWOX Data Marts Cloud.

What our tests mean for you

Two separate tests on our demo store’s data, 11 October 2026. Three takeaways:

• A plain total is a fair first question. Asked for one week’s revenue in three wordings, across three setups and 27 runs, every answer contained the agreed figure and said which orders it counted (9 of 9 in each setup). None had a wrong number.
• Check the label of the first figure. Asked for the “top line”, the agent held to our Data Marts led with gross revenue in 3 of 3 runs, labelled as gross, with net beside it. Write down the words your people use, not only the metric.
• Look hardest at breakdowns. In the second test, with another model writing database queries (SQL) from table and column names alone, 10 of 66 queries were wrong. Seven summed gross where the agreed number is net, all on breakdowns such as revenue by country; three came back empty. The check is easy to repeat: one number you argue about, three wordings, three fresh chats each, with and without your note.

What being held gives you

For people who see only the answer and never the query, four things:

• The definition is yours, not the model’s guess. In our runs the schema pointed to net. Where no such column exists, or your rule is the unusual one, the model has only its guess.
• A record. The request and the SQL that ran are logged, so a figure can be traced back. One exception we have seen: an answer the AI takes from chat memory without querying leaves no entry. We did not open the record in the 11 October test.
• Control over what the AI can reach. It reads the Data Marts you published, not every table in the warehouse.
• A refusal when the data is not there. The SQL-only setup of the 25-question test declined such questions too, so count this as a check that passed, not as a difference.

One such refusal, on 9 October 2026 in claude.ai. Asked “How many employees did we have at the end of Q3 2026? Use the OWOX Data Marts connector.”, Claude answered: “I can’t give you a headcount from this connector: it has no employee or HR data.” Chat memory was on and the reply shows it was read, so this is one run and not a clean-room one.

Being held did not give a steadier first figure.

Do you already have one?

You define metrics in dbt, or you maintain a Power BI semantic model or LookML. You have a semantic layer, even if only for some numbers; give the agent those and add one number at a time. Do not add a second place for definitions, ours included: two descriptions of one rule drift apart.

You have views and saved queries that people already trust. The definitions exist. In plainly named columns, our test suggests a current model will often find them, but nothing holds it to them or records what it ran. Rows 2, 4 and 5 can hold an agent, each under its condition. Calculated fields in Data Studio and formulas in sheets are definitions too, and an agent querying the warehouse never sees them.

Nothing is written down. Fill in one definition card for the number you are asked for most, and get the person who asks to agree it.

What it costs. Per number: find every place it is calculated today, write the card, move the logic into one place the AI reads, get sign-off. Sign-off depends on other people and is usually the slow step. Do one number and estimate the rest from it.

What no layer fixes

The AI can still be wrong, and the same question can come back differently. It can lead with a figure other than the agreed one, or answer from an earlier chat without querying, as one answer did in the 9 October run in our BigQuery guide. The causes are in why AI gives different answers to the same data question.

Your figures reach an AI company in most setups, and you choose which ones. Decide the list before you connect anything, and ask every vendor in writing how it is enforced and whether anything is kept or used for training.

How we tested

Told against held. In BigQuery, one question worded three ways: “What was our revenue for the week of 21–27 September 2026?”, “How much did we earn in the week…?” and “What was the top line for the week…?”. Three setups: raw SQL with read-only access to the warehouse; the same plus a two-line note (“Revenue is recognised only for completed orders. Cancelled and returned orders count as zero revenue.”); and held, the Purchases and Orders Data Marts through the OWOX connector with no SQL access. Three fresh runs of each wording, 27 in all, on Claude Opus.

Agreed figure: net revenue, $64,717.20. Gross, which also counts cancelled and returned orders: $77,267.82. Each cell shows the figure the answer led with.

The note was followed in all nine runs, and being told or held changed no figure. On “top line” the held agent read two field descriptions, one for gross and one for net, and matched the phrase to gross; neither the note nor the Data Mart says what “top line” means. No answer in any setup had a wrong number, a wrong join or wrong arithmetic.

Its biggest limit is the warehouse. Our demo data is tidy: the purchases view already has a column called line_net_revenue, so the definition was sitting in the schema under a plain name. All nine uninstructed runs queried that column, and 4 of the 9 answers named it as their reason. The note and the schema agreed, so nothing tested a note that the data argues against. It was also one model, a two-line note placed directly above the question, one clean week of 275 order lines, and three runs per cell. The runs were Claude Code sub-agents, not a chat app; the SQL in the raw setups is as each run reported it; and the held runs were told which two Data Marts to use, so choosing a Data Mart was not tested. It shows what happened here, not how often, and says little about a warehouse with untidy names.

25 questions. The second test, run the same day, asked 25 business questions of the same data. Claude Sonnet (claude-sonnet-5-5) wrote one query per question from table and column names alone, three times each. It could not run a query or look at values, and the task allowed SQL only, so it had no way to add a caveat. On the 22 questions the data can answer, 56 of 66 queries were correct. The 10 misses ran without an error:

• 7 returned a plausible wrong figure: gross revenue where the agreed number is net. They were breakdowns: by month, category, country, customer segment, and quarter against quarter. The line_net_revenue column was in view each time.
• 3 returned an empty result: they filtered on status = 'completed' when the data spells it Completed.

No miss was a broken join or bad arithmetic. The three questions with no data behind them were declined in all 9 runs. The model, the questions and the method all differ from the told-against-held test, whose raw-SQL setups could run queries and were never asked these questions, so we cannot say which difference mattered.

The same 25 questions through the OWOX Data Marts connector, one run each: 20 of the 22 answerable ones were correct, one led with gross, and one was declined although the data could answer it. One run against three is not like for like, and we claim no rate. Other limits: one model, demo data, and questions and reference answers we wrote ourselves.

What to send back to the person who asked

• No, we do not need to buy a semantic layer to use AI on our data. We need each important number written down once, where the AI reads it.
• OWOX, who sell one of the options, tested this on demo data. A plain revenue total had the agreed figure in every answer, though on one wording their own product led with a different, labelled figure. In a separate test, 10 of 66 AI-written queries were wrong, mostly through a different meaning of revenue. Neither test shows how much a written definition lowers that, so I will run the same check on our numbers.
• I will start with the number we argue about most. The slow part is agreeing what it means, so I need you, or whoever uses it, to sign off its definition.
• No setup guarantees a right answer every time, so for any figure that matters I will show you the calculation behind it.
• What the AI reads is sent to the company that makes it, so we should agree first what it may read.

AI in AnalyticsAI analytics agents replace your backlog, not your analystJuly 2, 2026→AI in AnalyticsAI analytics hallucination: why it happens and the SQL fixJuly 1, 2026→AI in AnalyticsAI analytics hallucinations: trace every number to SQLJuly 14, 2026→

See all articles →