- A semantic layer answers “what does this number mean?” It holds governed metric definitions and compiles them into the same query every time.
- An ontology answers “what things exist, how are they related and what can be done to them?” Filled with real records, it becomes a knowledge graph.
- A context layer answers “what is true right now, who may see it and what may be done next?” It combines both with identity, freshness, permissions and actions. Agents that operate, rather than only report, need all three.
If you have read about AI agents this year, you have seen three phrases used almost interchangeably: semantic layer, ontology and context layer. Some products describe a sales ontology as a semantic layer. Some BI suites put metric models and ontologies side by side. Some data platforms argue that a semantic layer is necessary but not sufficient, and that agents need a context layer around it.
The confusion is understandable, because the three overlap. But they were designed to answer different questions, and knowing which question you are trying to answer tells you what to build first.
Semantic layer: one definition per number
A semantic layer is a governed dictionary of business metrics. Each metric gets a formula, the dimensions it can be grouped by, and rules like filters, windows and currency. Metrics tools store these definitions as code, and BI tools keep them in semantic models. When someone asks for a metric, the layer compiles the definition into the same SQL every time.
For a growth team, this is where you settle arguments like “which ROAS?”. Meta reports purchase ROAS on its own attribution settings, Google reports conversion value over cost, Amazon reports ACOS, which is roughly the inverse. A semantic layer names the version the business steers by and records how it maps to each platform’s label.
One discipline is especially useful for agents. Each object type declares the measures it supports, such as spend or orders, and the dimensions they can be grouped by. The query interface rejects any measure or grouping that has not been declared. An agent cannot invent a formula; it can only use the ones the business approved.
What a semantic layer does not do well is answer questions about individual things. It is built for aggregates — revenue by region, ROAS by channel — and for humans reading dashboards. It says nothing about which campaign is promoting which product, or what the team decided about that campaign yesterday.
Ontology: the things, their links and their actions
An ontology models what the business is made of. It names the entity types (campaign, product, order, customer), their properties, the relationships between them (a campaign promotes a product; a product has an inventory position) and, in operational ontologies, the actions that can change them.
A common way to structure an operational ontology splits it into two halves. The semantic half is the nouns: object types, properties and links. The kinetic half is the verbs: actions, functions and the security rules that decide who can do what. Rules that fire when conditions on entities are met sit alongside them. An existing metrics model is often a good starting point, because it already names the entities the business cares about.
When an ontology is filled with real, connected records, you get a knowledge graph: an instance graph an agent can traverse. A helpful rule of thumb: the semantic layer answers aggregate questions; the ontology answers entity questions, like which campaign promoted this product and which orders it drove. We cover ontologies in depth in a separate post.
Context layer: what is true now, and what may be done
A context layer is the operational piece. It takes data from many systems and keeps it current, resolved and permissioned, so an agent can ask about the state of the business right now and act on the answer. Beyond the semantic layer, agents need three things: identity (records from different systems resolved into one entity), relationships (edges the agent can traverse) and actions (what the agent may do, with validation and audit). Add freshness, permissions and memory, and you have the working definition.
In practice, a context layer usually includes a semantic layer for metrics and an ontology for structure, and adds the parts neither was designed for: sync schedules, per-person access, a record of decisions and a controlled path to write back to the source systems.
- Context layerWhat is true now, who may see it, what may be done
- OntologyWhat exists and how it connects
- Semantic layerWhat each number means
Side by side
| Semantic layer | Ontology / knowledge graph | Context layer | |
|---|---|---|---|
| Question it answers | What does this number mean? | What exists and how is it connected? | What is true now, and may I act? |
| Holds | Metric formulas, dimensions, filters, windows | Entity types, properties, links, actions | Resolved identities, current state, rules, memory, permissions, action log |
| Changes when | A definition changes | The business model changes | Continuously, as the business moves |
| Typical owner | Analytics engineering | Domain experts with data teams | Data or platform team, with business owners for rules |
| Growth example | ROAS = attributed revenue ÷ spend, 7-day click | Campaign → promotes → SKU → stocked in → warehouse | “Hero SKU campaign is at 2.8×, 18 units left, client asked to hold spend” |
Which layer answers which question
A useful way to design around the three layers is to route each type of question to the part that answers it best: governed metrics from the semantic layer, operational records from the context store, documents from retrieval, and live state from a direct API read before any action.
Do you need all three?
If your agents only report, a semantic layer over a clean warehouse goes a long way. Every report computes ROAS the same way, and the agent can explain its numbers.
Once agents start to operate — watch accounts overnight, flag problems, propose budget changes — the other two become necessary. Without an ontology, an agent cannot connect a falling metric to the product, stock level or landing page behind it. Without a context layer, it knows the formula for ROAS but not that the numbers for the last three days are still being restated, that stock ran out an hour ago, or that the person asking is not allowed to see the client’s margin.
A fair summary: without a semantic layer, the agent computes the same number differently each time; without a context layer, it knows the definition but not what is happening today. And without one shared model of the business, agents built by different people drift apart and relearn the business with every project.
A practical order to build in
- Start with definitions. List the ten metrics your team actually steers by and write one definition for each, including how it maps to each platform’s label.
- Then identity. Map products and customers across your store, ad catalogues and marketplaces. This is usually the hardest part and the most valuable.
- Then the few relationships your decisions depend on. Campaign to product, product to inventory, campaign to budget and owner. Resist modelling everything.
- Then rules and actions. Write down the thresholds and approvals your team already follows, and give agents named actions with owners, instead of raw write access.