A semantic layer an agent cannot route around.
Every BI semantic layer is a convention. A human who ignores it writes their own SQL and nobody finds out for a quarter. An agent ignores it a thousand times an hour. Ward puts the definition, the permission and the log in the same plane, so there is one path to a number and it is the only one.
Three properties a semantic layer needs before agents reach production.
A semantic layer built for dashboards assumes the caller is a person who can be told the rules. None of these three were load-bearing when the consumer was a human opening a report once a week.
It has to be the only path
A layer agents can bypass is documentation. Ward resolves every metric through the semantic layer whether the caller is a person in the console, the chat panel, or an agent, and there is no second route to the raw table that skips it.
Permission is evaluated per query, not per user
An agent is not a seat. It runs on a schedule, against tables a human never opens, on behalf of whoever triggered it. Ward evaluates the policy at query time against the agent identity, so the scope holds whatever called it and whenever.
Every resolution is on the record
The question your reviewer asks is not what the agent is allowed to read. It is what it read last Tuesday. Ward logs the query, the definition it resolved through, and the identity that made it, for agents and people in one log.
Ward, Atlan and Timbr are three different layers.
They are compared against each other because they turn up in the same search, not because they do the same job. The useful question is which layer your problem is in.
| Atlan | Timbr | Ward | |
|---|---|---|---|
| Category | Data catalog and metadata governance | Semantic knowledge graph over SQL sources | Warehouse, semantic layer and agent runtime in one console |
| The question it is built to answer | What data do we have, who owns it, and where did it come from | What does this data mean, and how do these things relate | What is this agent allowed to compute, and what did it compute |
| What you define in it | Assets, glossary terms, ownership, lineage | An ontology: entities, relationships, inheritance | Metrics, grain, dimensions, and the policy that scopes them |
| Where it sits | Across the stack, over the metadata your systems emit | Between the query and the SQL sources it compiles down to | Between every caller and the data, agents included |
| Who writes the first draft | Your team, curated | Your team, modelled | Ward AI drafts it from the reports you already publish. You approve it before anything resolves through it. |
| Warehouse underneath | Bring your own | Bring your own | Stood up by Ward against your sources, or bring your own |
| Where it fits best | A large estate that needs to be findable and governed | A domain whose meaning is a graph, not a star schema | Agents going to production against data IT has to answer for |
Categories, not a feature checklist. Atlan and Timbr are both actively built and both ship past what a table row holds. Check current capability with each vendor rather than with us, and treat any row here that has gone stale as our error.
If you already run a catalog, keep it.
Nothing on this page is an argument for ripping out a catalog. A catalog answers what exists and who owns it, and Ward does not replace that. An ontology answers what things mean to each other, and where a domain genuinely is a graph, Ward is not a better graph. What Ward owns is the runtime: one resolution path, policy evaluated per query, one log covering people and agents. If you have a catalog and you are about to point agents at production, the gap you are filling is that one.
The longer version of this argument, for the person who owns the warehouse: for data and analytics leaders.
The definitions, and the policy that scopes them.
Ward AI drafts both from what you already publish. Neither binds until someone with the authority to say what a metric means approves the diff.
Semantic layers, catalogs and agents.
The questions that arrive with this one, answered without assuming you have picked a side.
A semantic layer for AI agents is the layer that decides what a metric means before an agent computes it, and what that agent is allowed to compute at all. It does the same job a BI semantic layer does for dashboards, defining metrics, grain and dimensions once, and adds two things agents need: the permission is evaluated on every query rather than assigned to a seat, and every resolution is logged against the agent identity that made it. Without it, an agent writes its own SQL and its answer is only as good as its guess about what revenue means.
Atlan is a data catalog and metadata governance platform. Its job is to make a large data estate findable and accountable: what assets exist, who owns them, where they came from, and what the business glossary calls them. That is adjacent to a semantic layer and often mistaken for one, but the two answer different questions. A catalog answers what data you have. A semantic layer decides what a number resolves to at query time.
They sit at different points in the stack. Atlan is a catalog and governance layer over your metadata, built to make an estate findable and accountable. Timbr is a semantic knowledge graph over SQL sources: you model an ontology of entities and relationships, and queries compile down to SQL against the databases you already run. If your problem is that nobody can find the data or say who owns it, that is catalog-shaped. If your problem is that the meaning of your domain is a web of relationships a star schema flattens, that is ontology-shaped.
If dbt is the only way anyone reaches your data, your metric definitions are already in one place and you have most of what a semantic layer gives you. The gap opens when something queries around it. An agent with a warehouse credential does not run dbt, it writes SQL, and dbt has no opinion about what that agent may read or any record of what it read. Ward keeps dbt as the transformation layer and resolves and scopes the query on top of it.
It removes the step where the agent guesses. An agent asked for last quarter revenue with only raw table access has to infer which table, which date column, which filters and which rollup, and a plausible wrong answer looks exactly like a right one. When the metric is defined once with its grain and additivity declared, the agent resolves the definition instead of reconstructing it, and a wrong rollup fails as an error rather than returning a number nobody catches.
Yes, and it is the normal case. Snowflake, BigQuery, Databricks or Redshift stay the system of record. Ward connects on a read-only service account, reconstructs the metric definitions from the reports your team already publishes, and resolves every query through them. Nothing is copied out of the warehouse to make that work, and revoking the credential returns you to exactly where you started.
One definition of revenue. Enforced.
Metrics, dimensions and grain defined once and enforced everywhere, including in what agents are allowed to compute.
How Ward's semantic layer works →- Ward AI drafts each definition from the reports you already publish. You approve it before anything resolves through it.
- Grain and additivity declared, so a wrong rollup is a failure not a number.
- Agents resolve metrics through the layer. They cannot invent their own.
One definition, and one path to it.
Ward AI drafts the layer from the reports you already publish. Nothing resolves through it until you approve it.
Read-only to start · your LLM keys · SOC 2 Type II underway · or book a call directly
Find out what your data has been hiding.
Tell us about your operation. We’ll show you the problems Ward catches, and the ones your current tools miss.