In short
A company's data is organised for the systems that write it. The CRM has an opportunities table with a coded stage field, the ERP has entries with numbered cost centres and the helpdesk has tickets with categories that have changed several times since go-live. People ask questions in another language, the language of the business. The semantic layer is the translation between the two. It is one of the three components of the Company Brain, the layer that knows the company: what data exists, where it lives, how it relates and who can see what.
The concept comes from business intelligence. Before it, each analyst wrote their own query to calculate revenue, margin or average ticket, and different reports showed different numbers for the same indicator. The semantic layer centralised those definitions: the metric was written once, with a business name, and the visualisation tools consumed it from the same place.
That design still holds. BI tools and data platforms offer semantic layers so that net revenue has the same formula on the executive dashboard and in the controller's spreadsheet.
In BI, questions arrive structured: someone picks the metric, the filter and the period on a dashboard. With AI agents, the question arrives in natural language, with ambiguities the dashboard never had to resolve. Asking how much the company billed to customers in the South last quarter requires identifying which metric is billing, which records are customers in the South, which quarter cut the company uses and which data the person asking is allowed to see.
Each of these decisions has more than one possible answer. The quarter may be the calendar quarter or the fiscal one. Customers in the South may be defined by billing address or by the sales region that handles the account. Billing may include or exclude taxes and returns. A person in the department settles these choices out of habit. An AI agent only applies the right choice if it is recorded.
The Company Brain semantic layer does this work before any query. It identifies the terms, looks up in the business ontology the definition that applies to each one, finds the entities involved in the knowledge graph and builds the query for the source systems.
A common approach in pilots is to ask the language model to write the SQL query from the question, with the database schema in the prompt. In a demo, with well named tables and simple questions, the result is convincing. In production, the model has to guess that a specific stage code means a signed contract, that customers in the South depend on a regions table in another database and that billing excludes returns.
Each guess is a chance of a silent error, because the query runs and returns a plausible number. The semantic layer takes these choices away from the model and puts them in definitions maintained by the accountable departments. The model receives the result already calculated, along with the definition used.
There is also an effect on cost. To generate SQL with some chance of getting it right, the prompt has to carry the table schema, example queries and notes on the fields. That text goes with every call and grows with each system added. With the definitions resolved beforehand, the model receives the result and a short summary of the rule, and the same task fits in a lower cost model.
Every query built at this stage carries the identity of whoever asked. In the Company Brain, permissions are inherited from the source system: a salesperson gets the billing for their own portfolio, and the finance leadership gets the consolidated figure. The filter is applied in the query, and the model receives only the rows the person can already see in the system.
The same design underpins data sovereignty. The data stays in the company's systems, the semantic layer queries the source at the moment of the question and the model receives only the slice it needs, served via MCP, the open protocol that connects models to data sources. In this architecture, no database is copied wholesale to the model provider.
Because the translation is explicit, it can be shown. The answer about billing in the South comes with the billing definition applied, the region cut, the period and the systems queried. Whoever receives the number can check where it came from without asking an analyst for the query.
The conversation about trust in AI changes subject. It turns to the definition applied and the source queried, topics that business departments know how to assess and correct.
The practical starting point is the set of questions that already reach the data team every week. They show which metrics, entities and cuts need to be defined first. A few well defined metrics serve more real questions than a complete model of the company that is still being built.
Each new metric comes in with a definition, an accountable department and named sources. From the second one on, the entities and rules already registered are reused, and the time to answer a new type of question shrinks as the company's vocabulary gets recorded.
If the company already maintains a BI semantic layer, it is a valuable source. The metrics defined there can be brought into the Company Brain, which adds the link to the graph's entities, permission inheritance and delivery to AI agents.
